Programs need structure and containment. There is a reason modern code editors have all kinds of visual facilities for emphasizing them. When staring at code, it's easy to lose focus or get lost in the sea of code. Without block delimiters, you're relying purely on indentation. It also saves little vertical space over delimiters; line breaks add vertical separation instead. Python gets away with it because most of its programs are quite short. Block delimiters have been a fixture in most programming languages since the 60s when displays and punched cards were limited to 25 lines or less. If they offered no value, they would have gone the way of the dodo early on.
Of all the wonderful ideas to steal from Ada, its object layout formatting is the one to leave behind, but Nim went for the wrong bag. The majority of object-oriented languages syntactically nest operations and data members inside the object declaration. Like block statements, it visually emphasizes the concept of containment or encapsulation. Ada, and now Nim, broke this well-established convention. Many would-be Ada developers are completely turned off by it, complaining it's weird and gross and offers no advantages. Unfortunately, Ada is stuck with this unfortunate design due to backward compatibility. Hopefully, it's not too late for Nim to change course.
Nim's object method calling convention was also in the bag with Ada's object layout formatting. It's equally a big point of contention with many Ada developers. Requiring the method's associated object in its list of parameters is a grave oversight and belies Nim's minimalist syntax goals. Ironically, Nim improved it to conform with the more common convention. While Ada can't undo its object layout mistake, it did implement an alternate syntax for its 2012 release, implying its calling convention wasn't well received. While the issue has been largely resolved in Nim, referring to it as syntactic sugar in the documentation is a begrudging dismissal of its value. I hope I'm it's a false perception.
Finally, breaking into Ada's safe and walking out with the bag containing its worst goodies while leaving behind its shimmering crown jewel warrants severe punishment, not for the heist, but for its poor appraisal. Ada's type specification is by far its best feature, which no other language has managed to achieve. The ability to specify constraints, and even static expressions, so exquisitely and precisely kept an otherwise overwhelmingly pedantic language relevant for several decades. The serves as metadata, providing the compiler with the programmer's intent and a beyond-AI level of optimization hints that would be otherwise unknown.
I hope it's not too late to change direction on these issues.
I'm sorry for not engaging much on a level of content. Posts like this, which if I'm mean boil down to "Nim should be more like programming language X" where X is Python, C++, Julia, Rust or whatever appear here from time to time.
And they always put me wondering how these changes should be realised, considering Nim is a language nearing it's 2.0 release with lots of code already (sucessfully) written and people actually using the language tend to have different complains.
As a side note, as much as I like the influence of the Pascal family on Nim, I've already encountered raised eyebrows a number of times for features stemming from this origin. We live in a world where C won afterall and likening Nim to Ada to attract the "Ada crowd", doesn't seem to be wise just from a standpoint of what people are used to.
2-3. Not entirely sure what you mean but see point 1.
2-3. As someone who spent several years with Ada, I'm happy that Nim doesn't go in the same direction. Having a declaration of type in two or more different files, isn't that funny, especially with large codebases. Encapsulation is a good thing, but spreading information around the code isn't my preferred style. ;)
That's more directed to @Araq response. About contract-based programming technique, require and ensure. I just hope that it will not go the same way as in Ada, via pragmas, but as code's blocks. In Ada, that kind of things can be huge and made the whole code hard to read. :) At the moment, contract-based programming in both styles is supported in Nim by libraries, thanks to macros' system.
2-3. It's a style issue. I'll add examples later.
would it be a huge success if it didnt have access to java's entire ecosystem?
I actually mentioned that too, but then edited my answer to avoid discussing that topic, as it was discussed countless times.
You can have rich ecosystem, without creating such ecosystem, if you have good integration with existing ecosystem.
Note how the speak procedure is associated with the Animal object,
It's not. Nim is not an object-obsessed language, so speak is just a normal procedure that happens to take an Animal as the first parameter.
increases the cost of learning (The learner must first know that "indentation" means to have more spaces at the start of a line, before learning further)
I vaguely remember that when learning programming, I found braces more confusing than indentation.
and the cost of restructuring the code (one must add/remove the correct amount of spaces when moving a block of code into another place)
Get a better editor.
It has a few issues that would make experienced developers hesitant to adopt it.
IMO the only problem that Nim has is the lack of network effect https://en.wikipedia.org/wiki/Network_effect
But if you think that your arguments are valid, you can always fork.
I don't see what Ada version of 6502 has over Nim's, see https://github.com/mratsim/glyph/blob/8b278c5/glyph/snes/datatypes.nim#L35-L89
type
# Note using uint8 instead of machine word size will add zero-extending overhead at every load
CPUStatusKind* = enum
Carry ## C - 0b00000001
Zero ## Z - 0b00000010
IRQ_Disabled ## I - 0b00000100
Decimal_Mode ## D - 0b00001000
Index8bit ## X - 0b00010000
Accum8bit ## M - 0b00100000
Overflow ## V - 0b01000000
Negative ## N - 0b10000000
Emulation_mode ## E - hidden / B - Break 0b00010000. Define if 6502 mode or 65816 mode
CpuRegs* = object
# General purpose registers
A*: uint16 ## Accumulator - Math register. Stores operands or results of arithmetic operations.
X*, Y*: uint16 ## Index registers. Reference memory, pass data, counters for loops ...
# Addressing registers
D*: uint16 ## Direct page addressing. Holds the memory bank address of the data the CPU is accessing.
DB*: uint8 ## Data Bank. Holds the default bank for memory transfers.
# Program control register
PB*: uint8 ## Program Bank. Holds the bank address of all instruction fetches.
PC*: uint16 ## Program Counter. Address of the current memory instruction.
SP*: uint16 ## Stack Pointer.
# Status register
P*: set[CPUStatusKind] ## Processor status
AddressingMode* = enum
# $number represents a number in hexadecimal representation
# Name # Example
Accumulator # dec a
Implied # clc
Immediate # inc #$12 or #$1234
Absolute # and $1234
AbsoluteLong # and $123456
AbsoluteLongX # and $123456,X
AbsoluteX # and $1234,X
AbsoluteY # and $1234,Y
AbsoluteXIndirect # jmp ($1234,X)
AbsoluteIndirect # jmp ($1234)
AbsoluteIndirectLong # jml [$1234]
Direct # and $12
DirectX # stz $12,X
DirectY # stz $12,Y
DirectXIndirect # and ($12,X)
DirectIndirect # and ($12)
DirectIndirectLong # and [$12]
DirectIndirectY # and ($12),Y
DirectIndirectLongY # and [$12],Y
ProgramCounterRelative # beq $12
ProgCountRelativeLong # brl $1234
StackRelative # and $12,S
StackRelativeIndirectY # and ($12,S),Y
BlockMove # mvp $12, $34
Cpu* = object
regs*: CpuRegs
cycles*: int
Nim had braces, was removed because no one used it for several years.
Almost. It was used within a company though which was writing commercial software in Nim. I decided to remove it because the grammar and parser are evolving and a brace mode makes that more difficult.
Thanks for clearing up my misunderstanding. I'm really sorry about my unsolicited advice. I didn't realize Nim is a hobby language. I was mislead by the incredible branding.
When you used the term "object-obsessed", I realized you guys weren't born when the software industry switched to OOP. It was the biggest revolution in software development. We all resisted it until we witnessed its jaw dropping productivity and improvements in code quality.
Please do stick it to the man and try out new things, but do realize you're rebelling against solutions to problem we solved fairly recently: text-only displays, monospace typefaces, 8x3 letter file names, command line, and procedural programming. Seeing young folks gushing over vim, terminals, and UNIX used to be cute, but it's now very depressing. There's no virtue, merit, or manhood in toughing it out like we had to in the old days. Relax, your testicles are not going to shrink if you program in OOP, or use a graphical user interface.
Anyway don't let an old fogey, Gen-Xer like me pee on your parade. Have fun!
Thanks for clearing up my misunderstanding. I'm really sorry about my unsolicited advice. I didn't realize Nim is a hobby language. I was mislead by the impressive branding.
You try to be clever with passive aggressiveness but that just makes you look like a fool. It's a technical forum, not a political one.
When you used the term "object-obsessed", I realized you guys weren't born when the software industry switched to OOP. It was the biggest revolution in software development. We all resisted it until we witnessed its jaw dropping productivity and improvements in code quality.
Since Java and C#, language creators went away from OOP. It didn't help code quality at all. Unless you call that kind of architecture quality https://github.com/MarkSFrancis/enterprise-fizz-buzz.
Worse, because of OOPs inadequacies and bootload of problems it created, people had to come up with "design patterns". In short, people had to transform themselves into compilers instead of let the language do what a machine do best, "automating recurring patterns".