Why NSIS adopted so strange language ?

Wladimir Mutel
5th December 2005 13:42 UTC

Why NSIS adopted so strange language ?
Hi,

These pushes/pops/exchs/labels/gotos make even VBScript look elegant in comparison. Did authors have too solid assembler background ?

To my mind, learning NSIS scripting language requires quite a lot of efforts from a person already knowing VB or something better. If I am wrong, please correct me.

Comm@nder21
5th December 2005 13:49 UTC

yep, its a bit of asm.
this is the thing behind nsis:
small, fast and flexible code.
in nsis you got about 200 instructions, maybe 300. you can do nearly everything with them. much more than just "install" programms, you can code real wizards.

in vb you may want to do even more and you got a less technical language.
this results in a slow language that requires gib runtime libraries to be available.
remember: nsis' overhead for a FULL FEATURED GUI installer is just 33k!!!

i guess this is the intention behind nsis.

DrO
5th December 2005 13:56 UTC

justin was very into assembler stuff from what i've seen and so it makes sense it happened with nsis. you have to remember that the project started out as just something to distribute winamp with and it sort of grew quite a bit.

things like logiclib, etc help to make using it a bit more human compatible but as commander points out, to get the flexibility you need to have low level access to things (as is the case with all forms of programming, etc) and so a asm nature to the scripting language is something that's remained.

-daz

Joel
5th December 2005 19:33 UTC

Hi Wladimir Mutel:

NSIS tries to be a unique programming language, not only a dump scripts in INI format :rolleyes:

In fact only takes encapsulation, polymorphism and someothers ot pop-up as OOP.

I say that is cool to have an installers that has option as same as if I was making an application...

PD: Yeah! An installer is an *application*, I know...you get the point :D

super-llooyd
8th December 2005 03:10 UTC

I believe the author is from Mars, that's why.

This tool is certainly useful but I agree with you that it will be even more useful if it was in english intead of martian.

Not that I have anything against martian, it's an as rich language as, say, English or French.
But it's just a bit difficult for us human.

super-llooyd
8th December 2005 03:12 UTC

BTW I have to disagree with some posters that martian is required to have a powerfull language.

English IS a powerfull language too.

C, C++, C#, ObjectiveC are all english, low level, and realize as much as pure assembly in much less lines

Pidgeot
8th December 2005 10:53 UTC

C# is not a low-level language, although I believe the rest of the C-family is.

C/C++ may be English, but it's incomprehensible if you haven't learned the language, unlike high-level languages. For example, assuming you don't know any programming, which of these make more sense: printf, or Console.Write?

guest1298
8th December 2005 12:44 UTC

Not long ago, assembly was attributed as "low-level" language, now anything that's not OO seems to fall into this category, maybe I'm getting old...

It's hard to classify NSIS dialect, it's somewhere between 2GL and 3GL. OTOH, it has 4GL features (page system, install types, sections triggered by selection of components, etc). It also has a plugin facility.
I see NSIS as a solid, no-bullsh*t tool that sprouted out of the necessities of real-life work. I take the simplistic implementation as hint of a flawless tool (now compare this to C++ compiler implementers who have spent more than a decade to get out of the hall of shame).

Overall, NSIS is a pragmatic tool with 4GL features usable in a 2.5GL fashion. YMMV.

Comm@nder21
8th December 2005 17:34 UTC

C, C++, C#, ObjectiveC are all english, low level, and realize as much as pure assembly in much less lines

they are all HIGH level languages, not low level.
especially c# and objectivec are high level, c and c++ are open for discussion, but they are far away from asm.

it IS possible to create small executables with c and c++, no question.
but i personally like the nsis language far better than c in the case of coding installers, because you can make less faults with nsis, and in case of one it always behaves the same way, so with a bit experience you will find your mistakes very fast.

l_d_allan
10th February 2006 20:24 UTC

These pushes/pops/exchs/labels/gotos make even VBScript look elegant in comparison. Did authors have too solid assembler background ?

To my mind, learning NSIS scripting language requires quite a lot of effort from a person already knowing VB or something better. If I am wrong, please correct me.

From another thread:

These things will become possible when NSIS supports compiler plug-ins.

ETA?
NSIS 2.1

NSIS 2.0 has to be finished first.

I am only barely familiar with LogicLib, but it looks like a very valuable addition to standard nsis. I write as someone whose favorite project was writing a 68k structured assembler in 68k native asm back in the mid 80's. asm is way cool <g>

BUT ... my 2¢ worth is to agree with the thread starter ... the push/pop and strcmp then jump +3 nature of nsis is archaic and probably holding it back.

I consider nsis an extraordinary accomplishment and definitely appreciate its minimal overhead size. A significant niche of the freeware apps I work on is for obsolete donated computers in 3rd world countries where POTS modems are still the norm, so size matters.

However, I would speculate that its minimal overhead of 34kb would only expand by several kb to support basic if-then-else and while-continue-break ... which is more than you really need to have the equivalent of for-loop and do-while.

My (non-counting) vote would be that nsis ver 2.x or 3.x have a significant degree of integrated if-then-else and while-break-continue support that is native to nsis, rather than an external plug-in with ${} macros.

But obviously easier said than done.

But this isn't criticism ... nsis is super. I suppose a case could be made that if you get into deep if-then-else nesting and/or outer-inner loops, then you need to rethink what you are doing.

JasonFriday13
12th February 2006 21:34 UTC

I find that the language is very easy to code, in some ways is similiar to C/C++, in other ways to html, again similiar to MFC (a part of C/C++).

At the moment I am learning C/C++, after coding in VB for a few years. I am coding a VB program in C++ (just to help teach me the language).

shouman
14th February 2006 04:16 UTC

I like the approach of author.

That’s it.

dandaman32
16th February 2006 06:21 UTC

The NSIS dev team has been considering changing the script language for some time now to be more like python...I know a bit of PHP, which is what NSIS is supposed to be like syntax-wise, but I still groan when I'm coding in NSIS and I want to do a loop or if-else-style conditional and the PHP code to do it in 2 or 3 lines pops right up in my head but instead I have to write it in 6 or 7 lines with NSIS. Still it would be nice to have features such as while/for loops and if/else conditionals because its more friendly to C++/Java/PHP programmers. The main concern of a language overhaul is backwards-compatibility - things like installer attributes (Name, Caption, OutFile) where do they fit in python?

One thing I certainly don't like with nsis is the script efficiency. With things like the ExperienceUI it's ok on newer computers but sometimes slow on old ones. When you compile an nsi file the code is parsed and written to a binary file, and the compiled code is again parsed by a runtime execution routine (which is ~25kb of the installer overhead). If the code were converted to native c++ at compile time this would speed things up (if this is possible - I hardly know any c++ so this is purely an idea)

In summary, the scripting language is great for those who are good at it (I've been with NSIS since version 1.91 which is about three years I think, and I've pretty much mastered it) but bad for newbies. Which is why there are so many posts on this forum offering $50-$100 for coding an nsis setup.


for(int i=1;i!=0;i++) {  // Infinite loop
  while(newScriptLanguage.location!="myHead") {
    for(int i=0;i<=100;i++) think(newScriptLanguage);
  }
  if(oldScript.compatibility==newScript.compatibility) break;
}

^^ My thoughts :D

-dandaman32

Afrow UK
16th February 2006 08:47 UTC

I think NSIS is fine the way it is. The only problem I used to have were following through old code... even with comments it was pretty hard. Now with LogicLib I never really have a problem.

-Stu

Comm@nder21
16th February 2006 19:05 UTC

i never have any problems reading my own code :)
may take some time on bigger functions but i know what to do :)

i love the jumps!