New Release Of Nim Borrows From Python, Rust, Go, and Lisp (fossbytes.com) 199
An anonymous reader writes:
"Nim compiles and runs fast, delivers tiny executables on several platforms, and borrows great ideas from numerous other languages," according to InfoWorld. After six years, they write, Nim is finally "making a case as a mix of the best of many worlds: The compilation speed and cross-platform targeting of Go, the safe-by-default behaviors of Rust, the readability and ease of development of Python, and even the metaprogramming facilities of the Lisp family..."
Fossbytes adds that Nim's syntax "might remind you of Python as it uses indented code blocks and similar syntax at some occasions. Just like Rust and Go, it uses strong types and first class functions... Talking about the benchmarks, it's comparable to C. Nim compiler produces C code by default. With the help of different compiler back-ends, one can also get JavaScript, C++, or Objective-C.
There's an improved output system in the newest release, and both its compiler and library are MIT licensed. Share your thoughts and opinions in the comments. Is anybody excited about writing code in Nim?
Fossbytes adds that Nim's syntax "might remind you of Python as it uses indented code blocks and similar syntax at some occasions. Just like Rust and Go, it uses strong types and first class functions... Talking about the benchmarks, it's comparable to C. Nim compiler produces C code by default. With the help of different compiler back-ends, one can also get JavaScript, C++, or Objective-C.
There's an improved output system in the newest release, and both its compiler and library are MIT licensed. Share your thoughts and opinions in the comments. Is anybody excited about writing code in Nim?
They took the worst part of Python (Score:2, Insightful)
Re: (Score:2)
Do you only use braces or do you indent as well?
Myh language 'Anal' (Score:5, Funny)
I use indents, braces and BEGIN and END so....
BEGIN
{
code here
}
END
I'm working on a new version of Anal called Anal++
Anyways, the language is designed to keep anal retentive developers arguing in nonsense meetings for years to come. "Oh no! Never put the curly braces and the BEGIN/END on the same line!"
"No, it's better to do so but indent 4 spaces and not a tab!"
"I STRONGLY disagree, you should never use tabs but SHOULD put the curly braces on the same line!"
"No no no! Indent AFTER the Begin but before the curly brace!!!!"
Re: (Score:2)
Which should be solved with an editor which shows the programmer what they want to see, not what others have typed.
Re:They took the worst part of Python (Score:5, Insightful)
Interesting how personal preference plays into it. But it also sounds like you haven't spent any real time with Python. Because it doesn't take long to get past the whitespace syntax and get on with programming. For most Python programmers, the block syntax is one of the things they like the most. It's true that a bad copy and paste or accidentally deleting some spaces in the wrong place can break things badly and potentially lead to subtle bugs. But in practice, that doesn't seem to be a significant problem. The fact is you should be indenting consistently anyway, so braces and semicolons are superfluous, and ugly.
I find I can write several pages of Python code and often it runs the first time without issue, which was never the case with any of the other languages I worked with, including C++. Invariably I'd forget some closing brace somewhere and a semicolon. Compile errors on first run are almost expected with C-like languages.
Python's real gotchas emerge more from its dynamic nature than its syntax; dynamic typing is a two-edged sword. Test-driven development is pretty much required for large applications.
Nim of course is statically-typed and has some measure of compile-time safety.
Re: (Score:2)
It's true that a bad copy and paste or accidentally deleting some spaces in the wrong place can break things badly and potentially lead to subtle bugs.
Well there's a ringing endorsement if I ever heard one.
Re: (Score:2)
Like I said, this is rarely a problem in practice.
Re: (Score:2)
Like I said, this is rarely a problem in practice.
In some languages it never happens at all, ever, which frankly seems like a good thing to me.
And why should it- it's called "whitepace" for a reason, and that generally means it shouldn't matter. Why should a missing (or extra) space crash your program?
If you like whitespace so much, why not program in it?
Whitespace: https://esolangs.org/wiki/Whitespace [esolangs.org]
Unispace: https://esolangs.org/wiki/Unispace [esolangs.org]
Re: (Score:2)
Re: (Score:3)
>There is no reason that indentation levels couldn't be automatically displayed based on the parenthesis data
Yeah, but nobody does that and even Apple and other huge companies have created horrible security bugs because they extended a branch of an "if" statement to two statements without adding the parens around the two statements that one would need then. Huh.
Yes, but automatic indentation in the editor would have automatically highlighted the mistake, and the programmer could have fixed it immediately. Why are computer programmers such luddites? We try to fix other people's problems with technology, but insist that our jobs should be carried out using 1970s technology.
Meanwhile, you can just have the indentation signify blocks which is how every human alive understands it anyhow and which require no special editor support and no weird manual fixes by the person editing it.
Humans may not vary much, but computer screens do. Consider that the whole point of things like HTML is to abstract out formatting in order to allow the same content to be rendered on various devi
Re: (Score:2)
Working in C years back I had to fix some code from a guy who pasted 1500 lines from a different application into the middle of an if statement block. He didn't even have the decency to wrap a function definition around it. It was just splurged into the code. It seemed to work fine but even with the parenthesis matching function in nedit it was hard to work out what block I was in.
In that case python would break, because the compiler reads the nesting level the way humans read it.
Re: (Score:2)
Re: (Score:2)
How about select the block, then :s/^ /##
Re: (Score:3)
You've obviously not used Python before. It's very easy to comment out a block of code and it doesn't require indenting anything, and it doesn't require an if (0) kludge. Your criticism and claim of being error-prone is not valid in this case. Python has a lot of gotchas and warts, but what you describe isn't one of them.
Re: (Score:2)
The fact is you should be indenting consistently anyway, so braces and semicolons are superfluous, and ugly.
How is Python's colon any less superfluous? Every block is preceded by a colon, and there is no situation where anything else can go in place of the colon. As far as I can see, the colon is 100% redundant within the syntax. (Excluding list syntax, naturally.)
Re: (Score:2)
Having tried to code in coffeescript, which has indentation without the colon, I much prefer python.
Re: (Score:2)
Re: (Score:2)
I really don't like the modern tendency towards dropping syntactic markers like parens or braces. We aren't writing the Torah on lambskin, where every scrap is precious, we have as much space as we want to make the code legible. And if typing the braces is a measurable percentage of the time you spend coding, you aren't thinking enough.
Re: (Score:2)
Agreed. I really don't understand why everyone complains about whitespace, when Python's almost religious insistence on counting from 0 is much more difficult to get used to. I mean, i get why range(8) counts from 0 to 7, but range(1,8) counts from 1 to 7? That makes no sense at all.
Re: (Score:2)
It isn't personal preferences. Braces are completely superior, using indentation alone causes problems:
*Mixing of the two causes programs to perform differently, but the bug isn't visible. This once cost me 3 weeks to track down a bug where one line in 30K from a contractor used a tab instead of spaces. This isn't the only time I've seen it cause bugs, just the worse.
*Copy pasting from the web is nearly impossible.
*When editing other people's code you don't know what to use. I actually just copy paste t
Re: (Score:2)
> The fact is you should be indenting consistently anyway, so braces and semicolons are superfluous, and ugly.
Why do python advocates always assume you have the luxury of exclusively working with your own code?
Re: (Score:2)
it doesn't take long to get past the whitespace syntax and get on with programming
You might get past it, but it will never stop bothering you. One of the more spectacular blunders in language design, imho. Another one, also in the Python camp, is the brain-damaged aversion to efficient executables. It says a lot about the language that it succeeds in spite of those two remarkable displays of incompetence. But Perl, not to be undone, came up with "there's more than one way to confuse things".
Re: (Score:2)
I've used languages that are whitespace sensitive. Generally indention errors throw compile errors. Which means the benefit is code ends up properly indented. Moreover because the compiler enforces indention rules indention becomes somewhat standard in the language community aiding human readability. Humans see whitespace more easily than punctuation. Readability is a big actual benefit..
Re: (Score:3)
That and the language (lack of) compatibility.
I wrote a project in 2.6 a while ago but a week before production I'm told that the machine would use 2.4
Imagine my surprise when I noticed that some keywords were working differently (something about the exception handling was looking like it was working, but breaking, I don't remember exactly what).
Now, if I want to use some scripting language to quickly so something (by opposition to do something fast) I use perl (cleanly) or bash.
(For the serious stuff I'm m
Re: (Score:3)
I prefer {} instead of tabs/spaces to define my code blocks. It's the only part of Python I don't like.
Same here. I confess I like the "syntactical sugar" of curly braces. I think it improves readability by an order of magnitude. The whole deal with using whitespace as code block delimiters seems retarded to me.
Re: (Score:2)
FOO()
{
BAR();
}
Re: (Score:2)
I assume you don't bother with indentation at all, right?
You assume incorrectly.
I love indenting; it's near and dear to my heart. In fact sometimes all I do is indent without actually writing any code.
Excited about writing code in Nim? (Score:5, Interesting)
Nim (*).
We are The Knights Who Say "Ni!".
(*) In Portuguese, "Nim" can be seen as a hybrid of "no" [Não], and "yes" [Sim]. Often used to express "I could, but I won't".
Re: (Score:2)
"and "nim" doesn't mean ANYTHING in Portuguese anyway."
It does. You are not Portuguese, otherwise you'd knew.
And, as a matter of fact, "Portuguese" is not an Obscure Language. It's the sixt more spoken language in the world.
Sorry about that.
Ac ouple of typos (Score:2)
In your reply you used "otherwise you'd knew" and "the sixt more spoken language".
I think you meant "otherwise you'd Gnu" and "the Sith more spoken language".
Re: (Score:2)
Mods, please +1 parent :)
And there is indeed a typo: I should have written "The sixth most spoken language".
Re: (Score:2)
If you are not a native, chances are you never heard it. Note that it's not an official Portuguese word.
Some references:
http://www.publico.pt/destaque... [publico.pt]
http://invisiblehand.blogs.sap... [blogs.sapo.pt]
http://visao.sapo.pt/actualida... [visao.sapo.pt]
http://www.jornaldenegocios.pt... [jornaldenegocios.pt]
Reminds me vaguely of Pascal with Python syntax (Score:2)
The example code I've seen from Nim reminds me a bit of Pascal. At least the use of the keywords proc and var. Glad they went with Python-style blocks instead of Pascal-style begin and end.
But nim does look like a nice language. The fact that it generates C code and compiles with a C compiler means that it could be integrated quite smoothly into projects using other languages.
Nim is on my list of languages to try some time if I ever need to write C-compatible code.
Readability? (Score:2)
"...the readability and ease of development of Python..."
I'll admit I'm not really a Python user, but I've seen lots of Python code and compared to other languages I've never considered Python to be very readable.
Re: (Score:2)
The language that's easy to read is the one you know well. I've used Python enough to think that it's easier to read than C or often C++ code that does the same thing. C's problems is indirections via multiple levels of pointers and macros. With C++ it is just that the language as a whole is too large, and I only know parts of it well, though it can include C's problems as well (but it doesn't need to).
Re: (Score:2)
The language that's easy to read is the one you know well.
That may be, but I admit I find syntactic sugar like braces and semicolons help me significantly in visualizing the code blocks, functions, etc.
FINALLY! (Score:2)
HAI 1.2 ;)"
CAN HAS STDIO?
VISIBLE "I've been looking for something to outdo LOLCODE in terms of pointlessness.
KTHXBYE
One obvious improvement (Score:2)
Just reading the docs, the first thing that pops out at me is that there is no need for a separate 'const' and 'let' keyword. They describe the difference as:
"The difference between let and const is: let introduces a variable that can not be re-assigned, const means "enforce compile time evaluation and put it into a data section":"
But the compiler can detect whether the expression on the right hand side of the let assignment is compile time constant, and "put it in the data section" if it is; no need for t
Re: (Score:2)
Another critique: the 'discard' keyword is unnecessary. "Forgetting to use a return value" is not a bug vector in my experience. No reason to force the programmer to tell the compiler "yeah I really didn't mean to use the return value of the function I called".
Re: (Score:3, Insightful)
Here's a big one: overloaded operators are terribad.
"The Nim library makes heavy use of overloading - one reason for this is that each operator like + is a just an overloaded proc. The parser lets you use operators in infix notation (a + b) or prefix notation (+ a). An infix operator always receives two arguments, a prefix operator always one. Postfix operators are not possible, because this would be ambiguous: does a @ @ b mean (a) @ (@b) or (a@) @ (b)? It always means (a) @ (@b), because there are no post
Re: (Score:2)
Here's another unnecessary weakness:
"Parameters are constant in the procedure body. By default, their value cannot be changed because this allows the compiler to implement parameter passing in the most efficient way. If a mutable variable is needed inside the procedure, it has to be declared with var in the procedure body. Shadowing the parameter name is possible, and actually an idiom:"
Re-using parameters as variables is very useful for writing concise code. I see no reason to limit things in this way. I
Re: (Score:2)
How so? There's only one name associated within the parameter internal to the function. So there's no ambiguity about which value is being assigned to.
I've *never* been confused about what it means to assign a value to an input parameter. Something like this is a common pattern and pretty useful:
function doSomething(a : String) // Now operate knowing that a is not empty
{
if (a == "") {
a = "some default";
}
}
That kind of code has never
Re: (Score:2)
That's only because of some weird syntactical rules of the functional language you are using in your example.
So in:
'let a = 5 if a = 2 else a'
the variable 'a' from that point on in the scope will I guess refer to this *new* 'a' introduced by the let expression, instead of the 'a' that was passed in? That's freaking confusing.
And the 'a' in the right hand side of the let expression is the function parameter 'a', not the 'a' being introduced in the left hand side of the let expression?
Sorry that's just obtus
Re: (Score:2)
Someone modded my comment as "Troll". I cannot even fathom what would lead someone to do that. My comment was a critique on the language. WTF is trolling about discussing the characteristics of a programming language in a discussion forum about that programming language?
Re: (Score:3)
Sorry, I can't disagree with you more about this.
As a videogame programmer, a significant amount of what I do is working with user-defined types like geometric vectors, matrices, quaternions, etc, all of which have well-defined operations that use mathematical notation, and it makes a big difference when I can write code in a natural and intuitive style. Just because someone could theoretically abuse a feature doesn't mean it's still not a useful feature. You could completely misname a function that adds
Re: (Score:2)
Well I guess we've had different experiences then.
matrix.multiply(other) doesn't seem that much worse to me than matrix * other, and in my opinion is more self-documenting since I know that a function is being invoked. And have you tried to actually write coherent operator overloading for any class? My god it's ridiculous in C++; the syntax for doing so is awful and the number of niggly details you have to get right or leave yourself open to weird bugs that will only show up much later when someone else t
Re: (Score:2)
"so why does Nim need a feature only useful in video game inner loops"
yeah that is a bit of a straw man, I admit. We never established that operator overloading is a feature only useful in video game inner loops.
But I will say that I think it's generally only useful in a narrow and small subset of programming problems: those for which mathematical constructs already exist and for which math operators are meaningful. Most people don't write code using quaternions and matrices. General control logic and da
Re: (Score:2)
That old story again. You know what the + operator does? It adds two things together. How it does that is really none of your business.
You probably think that you know what happens when you write x + y. Well, you don't. It all depends on the type: if x and y are integer, an integer addition instruction is used. If they are floating point a floating point addition instruction is used. And if one is integer and the other floating point there is first a conversion, and then a floating point addition. If one is
Re: (Score:2)
The ways that + can behave in C can be enumerated without knowing anything else about the program. But overloaded operators in C++ cannot be enumerated without knowing the types involved and doing an inspection on those types to see if the operator is overloaded.
It's a trade-off. Sure operator overloading allows some concise representations. But it's information hiding. That's not a trade-off that I think is wise to make. Other people obviously differ in their opinion.
Re: (Score:2)
I've got to disagree...though not totally. ISTM that overloaded operators need to be marked, rather than eliminated. I once suggested that overloaded operators be enclosed in pipe chars, e.g. |+|, but nearly any mark would do. And this be only used for operators. I also wanted to allow alternative symbols, names, etc. to be used for operators, but there I ran into the precedence problem
Re:One obvious improvement (Score:4, Insightful)
I strongly disagree.
The first mistake is not knowing C++ well. a+b means operator+(a,b). It's a function call with a funny syntax. No more, no less. Now we're on to function calls, nothing in your language stops someone from writing a function called add() which does something silly. Or sensible.
Why is it worse having a+b than add(a, b) when a and b are complex as per your example?
Re: (Score:2)
a + b for complex types isn't really the trouble, since we know that the compiler can only accept that syntax if the + operator has been overloaded.
What's worse is overloading [] or -> and competely fooling the programmer who has no way of knowing, without exhaustively scanning all source files, whether or not those operators are doing something unusual.
Information hiding. It's bad.
Re: (Score:2)
Nope that's no different.
a[b] means index(a, b). Information is no more hidden than if you have to look for index() versus looking for operator[]. Operators are not magic, they're just functions with an alternative syntax. If you have a problem where programmers are fooled because someone keeps committing an index() function to the repo which does something else entirely, the problem isn't overloading, it's that you're not doing code reviews properly.
Re: (Score:2)
If you actually write code that does lots of math on vectors and matrices and so-forth, you might change your opinion. Added to which, the oft-trotted-out argument that '+' might be doing something other than adding due to overloading is moot, since the same can be said of a function called 'Add'.
Re: (Score:2)
I do like that kind of polymorphism because it allows the "same" operation to be applied to different types; however, readability becomes a bit more difficult because I have to know, in my head, all of the types of all arguments to a function call in order to know which form of the function is being called, if I am reading the code and trying to follow the flow to understand what the code is doing.
So it's a trade-off. To be honest, the number of times that I've really, really wanted that kind of polymorphi
how does this compare to D? (Score:3)
Nim sounds similar in its goals to D [wikipedia.org], another batch-compiled statically typed language with GC. The main difference is that Nim seems to innovate a lot syntactically. How do the languages compare otherwise?
Re: (Score:2)
Re: (Score:2)
So, that still leaves open the questions...
What benefits does Nim derive from being syntactically different from C++?
And how does it functionally improve on D?
Unless there is a strong reason to deviate from it, I would like a new language to be as similar to C++ as possible.
Re: (Score:2)
Re: (Score:2)
So? We're not talking about "the whole C++ thing", we are simply talking about not gratuitously inventing new syntax so that the language feels familiar and is easier to learn. D and C# both retain much of the feel and syntax of C++ while having none of the problems you mention.
Nim breaks radically with existing syntax, and I don't see a good reason for it so far.
Parallel support? (Score:3)
Looks like another language that does not thoroughly address parallel processing. With the mention of go, I was hoping for something like goroutines (one of the few things I like about the language) - but no. Doesn't look like it.
programming nim: fun; debugging nim? (Score:2)
I found programming in nim fun; when I looked into runtime debugging nim, I wasn't very convinced I could actually use it for anything anytime soon.
Use case? (Score:2)
Re: (Score:2)
What's there to discuss, then? What new thing does Nim bring to the table?
Show me some code that shows how Nim can do things better. It's more convincing than a list of bullet points anyway.
Re:Whitespace takes the most space (Score:4, Interesting)
Show me some code that shows how Nim can do things better. It's more convincing than a list of bullet points anyway.
Wrong question. The single most interesting idea I've seen in Nim isn't something you can see in a piece of code: it's how it aids the programmer in optimising code late. It's only the memory management system, but the idea is that you prototype your code with a garbage collector switched on, and once the code is working, and assuming you need the performance gain, you code up your own memory management routines tailored to your code.
It's an idea that seems logical, but is frustratingly uncommon, and is not normally an in-built feature of the language, but rather just a part of the dev workflow (for example: use a generic sort algorithm from a library during prototyping, then analyse the data you're working with in large-scale tests and select or code a more efficient implementation for your situation). The weakness in doing this manually is that it first means tying your codebase to a library, with its various quirks, and then potentially rewriting vast chunks of code to get it to work with a different library (and then there's the risk of cascading changes).
I think Nim's approach is a small step in the right direction, taking us towards logic first, optimisation later.
Re: (Score:2)
doesn't sounds all that unique. Lots of languages let you muck with memory allocation. For example C++
Re: (Score:2)
doesn't sounds all that unique. Lots of languages let you muck with memory allocation. For example C++
But C++ doesn't have a garbage collector, and more generally most languages have [i]either[/i] implicit garbage collection [i]or[/i] explicit memory management -- Nim has both, allowing you to ignore memory management completely until you're ready to optimise -- that's a very useful thing. I'm no expert on languages, so I don't know which of the more advanced multi-paradigm languages have similar options -- but it's something that's still missing from mainstream languages.
Re: (Score:2)
Mod parent up. Excellent short description about what Nim is bring to the table.
Re:Whitespace takes the most space (Score:4, Informative)
There's nothing to discuss since any algorithm can be written in any turing complete language.
There's plenty to discuss, since the ease with which you can express yourself matters greatly in any practical sense. However, the progress we have actually made in this area is not nearly as impressive as one might hope - new languages mostly bring us the same thing, but with slightly different syntax. Real breakthroughs are very, very rare. Remember the 4GL initiative from Japan in the nineties? Still waiting for that killer language... The closest I've seen is the Wolfram language. Maybe that's the way forward: a massive support library and huge, online databases.
As for Turing machines... On a machine with finite memory, all states the machine can be in can be enumerated, and each state always leads deterministically to a single next state. Since the total number of states is finite (very large, but finite), this means that at some point it must either return to a previous state, or halt. If it returns to a previous state, it will then continue to loop forever (since each state deterministically leads to a single next state). Thus, if you have the capacity to track state changes for long enough, you will be able to determine if a program will halt or not.
And yet, there's Turing's proof. Why the discrepancy? Well, simple: a Turing machine has an infinite tape, and can therefore produce not a finite, but an infinite number of states. Any computer we have in the real world does not have infinite memory, and is therefore not a Turing machine. To be considered Turing-complete, a language must be able to simulate a Turing machine - and that's actually impossible, since it can never meet the "infinite tape" requirement. You might claim that "any algorithm can be expressed in any Turing complete language", but since we don't have any, that's really a moot point, and we would perhaps be wiser to focus on other aspects of the language rather than a theoretically impossible, and perhaps even undesirable feature.
Your move, AC ;-)
Re: (Score:2)
And yet, there's Turing's proof. Why the discrepancy? Well, simple: a Turing machine has an infinite tape, and can therefore produce not a finite, but an infinite number of states. Any computer we have in the real world does not have infinite memory, and is therefore not a Turing machine.
A slight correction, perhaps: for practical purposes, and for algorithms that use memory bounded linearly in time, it's effectively infinite because we can just keep manufacturing it.
Re: (Score:2)
To be considered Turing-complete, a language must be able to simulate a Turing machine - and that's actually impossible, since it can never meet the "infinite tape" requirement.
Languages are not machines. Languages have no memory limitations, and therefore have no trouble simulating a Turing machine.
The fact that we run code written in those languages on finite machines does not change the Turing-complete nature of the languages.
Re: (Score:2)
But what is the value of an algorithm that you can't actually execute?
In the practical world, language efficiency actually matters and is a reasonable thing to discuss.
Sure, that's true. But it has no bearing on the question of whether a language can accurately be called Turing Complete -- and Turing Completeness also matters, because it defines the class of algorithms that can be implemented in the language. What's the value of an algorithm that you can't implement because the language lacks the necessary expressive power? Except in very limited circumstances, Turing Completeness is a prerequisite. Without it, there's no point in discussing efficiency.
Re: (Score:2)
FWIW Wolfram's language is a functional programming language. If you want to learn a very cool language that takes those ideas much much further I'd suggest Haskell.
Re: (Score:2)
By that logic, if I want a production script to copy some files around and test a few things I should code it up in C++ or ASM since all languages are technically equally suited for the task.
Re: (Score:2)
So its pascal without begin and end?
Re: (Score:3)
Seeing as it's been around and alive for nearly 10 years, I'd say your prediction is not going to be true.
Re:Hey look! (Score:4, Insightful)
Ruby is 22 years old, and regularly someone will come out and say this language will take over the world. And despite a loyal user base, it never really took off. It had a bit of success with the ruby-on-rails framework but it didn't last.
Nim is a bit like that, except that it didn't even have the small success Ruby had.
Re: (Score:2)
I am still waiting for FORTH and SMALLTALK to rule the world.
Re: (Score:2)
Not to mention Lisp, Eiffel and ADA.
Re: (Score:3)
Ada was huge in aerospace but the last time I was there they were using this abominable ada to java source code translator.
Re:Hey look! (Score:4, Insightful)
They do. The object system from smalltalk is the basis of the one used in Objective-C, Java, Python, Ruby among others. Tablet oriented Oses like the dynapad are selling about a billion units a year in smartphones and tablets. The MVC design pattern is the standard for GUIs. And finally WYSIWYG is absolutely a standard in wordprocessing which has now many times over more popular than any other document construction system.In what possible sense doesn't smalltalk rule the world?
As for FORTH the influence is more on the hardware side. Most of the more sophisticated chips (or subsystems within chips) in your computer use a microcode compiler based on the ideas of FORTH. pdf is based on forth. HP RPL is based on forth and influenced a whole generation of programers early in teaching them how to construct dynamic systems out of small parts. I'm not sure if I'd say "rules the world" but "embedded itself into the DNA of computer science forever" is likely accurate.
Re: (Score:2)
No, sorry, it's not.
Re: (Score:2)
A trip to Wikipedia before posting is all you need to stop embarrassing yourself.
Re: (Score:2)
I don't need to make a trip to Wikipedia, being familiar with the implementation of three of those languages.
Objective-C's object system is indeed based on Smalltalk's.
Java's is not at all: it lacks duck typing, uses interfaces, lacks many of Smalltalk's dynamic features, and has separate value types.
Python's object system is also very different, with its implementation of objects as hash tables, and its use of bound methods.
Bu
Re: (Score:2)
You missed Ruby, which resemblances Smalltalk in many ways.
The original poster didn't say the object systems are similar, but that Smalltalk's object system is the basis of the one used in those languages. Java and Python did a poor job of course.
Re: (Score:2)
The OP claimed (in context) that "Smalltalk rules the world". But the fact is that Smalltalk's object system has failed. The object systems that have succeeded are either considerably more efficient and statically typed (Java, C++) or considerably more flexible (Python).
Re: (Score:2)
Java was successful not because of its object system but because it was C-like and free of charge at a time when Smalltalk was very expensive. C++ is a mess, I doubt its SIMULA inspired object system had anything to do with its success. Python was only the sane alternative to Perl.
Ruby and Objective-C are the closest to Smalltalk and are very successful because of that.
I don't understand how you can extrapolate that to say that Smalltalk's object system failed. Even more so when the OP's idea of ruling the
Re: (Score:2)
Smalltalk has been influential, but some of its key ideas have failed. For example, its approach to software development (browsers, images) has largely failed. Its "everything is an object" approach has failed. Its syntax has failed. Object and type systems of major languages (Java, C#, C++, Python, JavaScript) are substantially different. Concurrency has gone in a different direction.
And we're not catching up with the past; Smalltalk has been mined for ideas to death and every idea in it has been tried mul
Re: (Score:2)
Why wait? Take matters with your own hands and make Smalltalk great again.
Re: (Score:2)
Sure but that wasn't what the original poster was talking about. Whether or not it has a fraction of the success of Ruby, as long as someone somewhere wants to maintain it, it will live on.
Re: (Score:3)
Ruby is a good example of the magpies in action - they hop from flavor of the year language to language to have something new on the resume and to get in while it's still fun and they can still be trendmakers.
Then they flocked off to whatever the new hotness was (I've lost track) and left it as 'That language you use for Rails'.
Python people just want to get their work done and have the code be maintainable, so it endures.
Nim is somewhat interesting, but even that article says that now the hard work starts
Re: (Score:2)
I've been using Ruby every day for more than 10 years, and I'm still learning new stuff every day.
It's possible to write beautiful, productive, readable and maintainable code with it.
Rails is a cool project, but what bothers me is that it changes a lot between versions, sometimes just for the sake of changing stuff. For many people, Rails is the only Ruby project they know, and this might be very confusing because so much "magic" happens behind the scene. 6 months later, this magic has been changed to somet
Ruby (Score:2)
Ruby is along with Python and Perl one of the big 3 scripting languages. It seems pretty stable at over 1% of programs according to TIOBE and is currently surging again to 2.5%: http://www.tiobe.com/tiobe-ind... [tiobe.com] . At this point obviously Python is in first place but I'd say Ruby is mostly tied with Perl for 2nd. How is that not success? Certainly it isn't a top 5 language but a consistent top 100 is a successful language.
As for nim I think I've only heard of it a few times so I'd agree that language
Re: Hey look! (Score:5, Funny)
Shhhh... don't reveal the Secrets of NIM
Rats, I really wanted to reveal the secrets...
Re:Hey look! (Score:5, Insightful)
Then I clicked through from the standard Slashdot post to the Infoworld article to see what was really going on.
Nothing good.
(1) The language is (after _10_ years of effort) in release version 0.16 (2) under the heading of "What it takes to get to 1.0" we get: "[...] Nim's biggest disadvantage right now is the relatively small community of users involved in its development -- an understandable drawback given its status as an independent work. Development is led by the language's creator, Andreas Rumpf, but it's not a full-time effort. Compiler bugs still pop up regularly. Even moderately old code examples may no longer be useful due to changes, and it can be hard to find out what those changes are without closely following the project's development. [...]"
Right. I've heard enough. Keep that crap and don't bother posting until you've got version 1.0 done.
I would be interested in a tool, not in yet another half-baked DIY project.
Re: (Score:2)
I lurk on the Nim IRC channel sometimes. The toxicity there can be unbelievable.
I don't know any of the people who created any of the non-DSL languages I use every day. I don't know if they worship Natas and sport Hitler Mustaches or if they have some kind of oxymoron "tolerance" thing going on like the Rust heads. I don't know if they are into Satanic rituals while being employed by NSA as part of ongoing efforts to compromise all the worlds systems.
How can anyone take the language seriously when they have to put up with so much anger and rudeness from its community?
How can anyone seriously care? People select languages for RESULTS not social hour. The only thing I care about is technical merit..
Re: (Score:2)
I've looked at Nim a couple of times, most recently earlier this month. I didn't get much beyond looking, as I need various libraries as well as the basic language, but it did look interesting. If you only need one or two external libraries it might be worth your while to look at it more deeply than I did.
But I really doubt that their code generation averages as fast as decently hand-crafted code. But it may well be a lot faster to write.
Re: (Score:2)
How can anyone seriously care?
Because languages are not static. Their future depends on the development community.
Re: (Score:2)
The chief counterexample to the statement "Python is strongly typed" is that almost anything can be used in a boolean context.
Is it? I guess that's just a matter of interpretation, but to me, all it means is that Python has its own specific definition of truth and falsity. Many languages seem to have that.
Re: (Score:2)
What if God Trumped all of us... Combed one over all of us...