571 karma · joined June 5, 2013
Stanza feels like a Lisp with infix syntax. The closeness to Lisp explains why Stanza makes a semantic difference between "f(x)" (which is a function application) and "f (x)" which is a sequence of two elements (f and x). Unlike Nim which is strongly typed, Stanza allows to mix typed and untyped data freely.
[1] lbstanza.org
[2] nim-lang.org
I like that because I use key desktop macros heavily.
> and do screen grabs of other windows.
I like that since it enables me to make screen shots of any application.
> X11 does not support different scaling on different monitors that are connected to your computer.
I use two monitors with different resolutions, one horizontal, and one in portrait mode. They work perfectly, also with virtual screens. What you possibly mean is that X doesn't support that by default. Nevertheless, it's possible if the graphics vendor provides appropriate drivers.
Nim doesn't depend on LLVM. It works also with GNU C.
Interesting! So, it should basically be possible to bootstrap from source using OCaml and the old source from the Git repository.
It's interesting that OCaml was used to develop Rust since OCaml is also used for formal verification of SPARK (a dialect of Ada) which is another language for safety critical applications. OCaml seems to be a good choice to invent new big languages.
I think code safety is not an issue here because the Posix tools (and Unix/Linux as a whole) have already proven their extreme reliability.
The only real advantage to rewrite the Posix tools is motivation. A rewrite in a modern language like Rust will likely keep maintainance longer alive than old C code that no one likes to maintain.
It's the same reason why a new display manager (Wayland) is wanted instead of X11. There is basically no technical reason to replace the X server which works very well to this day. However, there are not much people anymore who like to maintain the old X code, or to support new graphics cards in X.
That's painful. It's one big point which Nim [1] does better. It compiles to C and bootstraps from C. That makes porting to other platforms much easier.
I don't understand why Haskell and Rust don't provide bootstrapping from C. Did they write the first compilers with Assembler?
> You just don't notice it because these two languages are already part of the base system.
C (not C++) has become the essential foundation on any platform. You will likely not be able to sell your embedded system unless it supports C.
Unfortunately, there is also evil genius (in wickedness) of individuals [1]: Jack the Ripper, Hitler, Marx, Lenin, Stalin, Pol Pot, Hussein, etc.
[1] https://www.ranker.com/crowdranked-list/the-all-time-worst-p...
Groups are usually always mediocre since there are not many geniuses. It explains why systems of extreme group thinking like Communism never work out.
It is interesting that even outstanding things created by comittee - Ada for instance - are barely successful while inventions of individuals - Wirth's Pascal, Kernighan's C and von Rossum's Python for instance -- were/are widely successful.
Wouldn't it be easier to develop a very basic OS core in Rust, and a simple Lisp 1.5 interpreter written in Rust as foundation for a full blown Lisp?
Why do you want a Rust with Lisp syntax? I don't see the benefits of such a "Lisp" if you take the core benefits of metaprogramming at runtime away which depends on the equality of code and data.
Safe software can also be written in other languages than Rust. Ada is still industry standard of safe programming today. Even Lisp can be used to write safe software since Lisp's memory management takes care of possible pointer problems.
Rust shines in the field where Mozilla developed it for -- safe Internet browsers. However, safe Internet browsers could also be written in Ada and Lisp. The Lisp version would just not be as performant as Ada's and Rust's.
I agree with that. Regarding MS Office compatibility however, you don't need to stick with Libre/OpenOffice. There is also SoftMaker Office.
Fortunately, and that's a big point for Linux, the user decides the further direction. KDE has become very usable again, and Gnome is on the way. In the Windows and Mac ecosystems the users have no choice.
Regarding Limux, I followed the Limux project pretty closely. I think this project failed only for political reasons. This conjecture is supported by the fact that most reports about Limux in Germany published only opinions of technically clueless political leaders while the opinions of the actual users were barely mentioned, if mentioned at all.
The point is, Limux had to fail by any means since MS could never afford a Limux success. If Limux would have been successful (and it actually looked promising) it would have been an example to follow for the whole world -- just for reason of license costs and source control.
I also appreciate that LibreOffice sticks to the classical menu system and doesn't overload the desktop window with a multiple of icons where most of them are barely used.
I think the most reliable source of information in this time of spreading "fake news" is personal witness by known people.
When I encountered Forth first (6502 figForth) I felt it quite convenient. At that time there were only two other options - Basic and Assembler. Maybe that most developers today are too pampared by all the available IDEs for other languages. It's the same attitude why so many people stick with Windows instead of learning OSX or Linux, despite all the flaws of the Windows ecosystem.
> lack of memory management that are in every other high-level language
As already mentioned, I consider Forth suitable for tiny systems, iOT, Firmware etc. I would never use Forth for big software. I would not use even C++ for that. In that area Ada, Rust or Nim works much better for me.
This is an example of "ugly" Forth code. It's ok here to make the code as short as possible.
In reality I would write (educational) Forth code this way. The texts in parentheses are comments.
( compute Hypotenuse sqrt[a²+b²] )
: hypo ( a b )
swap ( b a )
dup * ( b a² )
swap ( a² b )
dup * ( a² b² )
+ ( a²+b² )
sqrt ( result )
;
( Application: 1.2 3.4 hypo )"My VLSI tools take a chip from conception through testing. Perhaps 500 lines of source code. Cadence, Mentor Graphics do the same, more or less. With how much source/object code?
– Chuck Moore, the inventor of Forth
Source: http://yosefk.com/blog/my-history-with-forth-stack-machines....
500 lines are actually possible since Forth words are threaded. That means, any new defined word w can take advantage of all available predefined words. Follwing words can take advantage of w, etc. Forth words are not just simple procedures but they can also comprise new syntax structures. Forth words can be "procedures" or "macros", and both can be mixed freely.
Threaded code was the main reason why Forth was so successful in the first years when memory costs were a real issue.
That's a statement of someone who doesn't understand Forth. Of course, one can write ugly code easily. Any language with raw power (Asm, C, Forth, Ada) needs a disciplined developer to get beautiful and maintainable code. Forth code can be really beautiful if the vocabulary is well thought out.
I consider Forth the best choice for tiny iOT devices, Firmware, and other essential things which can be kept simple and stupid, following the KISS principle which works very well in many cases.
Our vastly proliferated software security problems come from complexity which developed by despising the KISS principle. Many developers didn't choose the simplest way, they chose the most convenient way. Now, we realize that keeping things simple and stupid is not that bad after all.
So, we cannot trust even formal verification?
> it’s a factual statement. In formal analysis, definitions really, really matter!
If lack of definition implies flaws in formal verification, does that mean we need an additional formal verification of formal verification?
Update:
> We need machine-assisted verification of protocols, preferably tied to the actual source code that implements them.
Haskell, here is your opportunity :-)
Really? If you mean software for the RISC-V/x86 emulation you are possibly right. Regarding RISC-V in general however your statement is not true.
Fabrice Bellard has published a working Linux on 32/64 bit RISC-V [1]. There is no reason that we could not expect Linux to run on real RISC-V hardware next year on a SiFive Quadcore.
[1] https://news.ycombinator.com/item?id=1878220
[2] https://common-lisp.net/project/mcclim/excite.html
In classical OS (Linux, Windows, Mac) the developer is responsible for seemless integration (in KDE or MS Office for instance). It is easy to break design guidelines here which causes ugly interoperation, or even lack of interoperation.
I believe application performance is important on servers. It makes a difference if your Shop software written in Python is able to handle 50 requests per second, or if the same software written in Nim can handle 500 rps. And by the way, Nim provides static typing which helps a lot to catch errors at compile time.
It reminds me of the quote "Who knows only hammers as a tool considers every problem a nail".
Also the typical claim that LISP just means "lot of silly parentheses" points out that those critics have never tried to develop in the Lisp way. Ironically, as time goes on and complexity rises, more and more developers appreciate new features which have been available in Lisp for more then 50 years -- lambda expressions, maps, and macros for instance. Lisp was so far ahead of its time that people today still have problems to realize what is so fascinating about Lisp, and why Lisp machines are so awesome. They should take a look at the graphical shell [1] of McCLIM [2] (a revival of the famous CLIM GUI) to see that powerful desktop computing can be very different.
[1] https://common-lisp.net/project/mcclim/static/media/screensh...
Companies want mediocre developers for mediocre languages (Java, C++, C#, etc.) because mediocre developers can be replaced easily, and because they get lower salary due to great competition.
Mediocre languages are just good enough to implement the things which need to be done. All their features are comprehensible by mediocre developers. That's another reason why only mediocre languages become mainstream.