Recent Forum Posts
From categories:
page 1123...next »

I wholeheartedly agree with the sentiment of the article, but admit that the topic of exceptions is a tricky one, especially when it comes to the low level application stack.

C++ is a powerful mess. It lacks elegance and fails the "less is more" principle. The success of Java in complex systems and as a business language should be, to a great extent, attributed to the failure of C++.

C++ is neither a proper high level language nor a system programming language. It's stuck in the middle. Despite its undeniable ugliness, it added a lot of value and allowed the authors of C#, Java, Kotlin to learn from its mistakes.

It was a wonderful idea to move away from C++ and write nanomsg in C. It's just a lot cleaner this way. ZeroMQ should have been written in C in the first instance.

by Vlad (guest), 14 Jun 2019 12:04
by best online training (guest), 11 Jun 2019 09:47
Hannes (guest) 09 Jun 2019 16:49
in discussion Hidden / Per page discussions » Type-safeness in Shell

Might be worth glancing at TypeScript's type definitions. By using .d files written in a a definition language, type safety can be added on top of JavaScript. Good ones are taken up into a repository of officially supported typings. With a similar approach, type information could, at least to some degree, be added to command line tools.

by Hannes (guest), 09 Jun 2019 16:49
Thomas Gebert (guest) 30 May 2019 19:49
in discussion Hidden / Per page discussions » Type-safeness in Shell

You know, I never really thought about it, but I do wonder if someone could encode a dependent-type-system into a shell. Languages like Idris have a REPL, indicating that they *can* run in interpreted mode, so conceivably you could have some kind of typesafe pipe that handles it.

Awhile I took a stab at making a Lisp-based command line shell, which was going to play nicely with JSON and Protobufs by default, but my computer crashed, I got a new computer, and forgot that I had started that project until right now. I should start that again.

by Thomas Gebert (guest), 30 May 2019 19:49
bsbsbs (guest) 23 May 2019 20:39
in discussion Hidden / Per page discussions » Type-safeness in Shell

It's a tempting idea. Funnyways, strings are often enough. When you ps and grep PID it is an integer but who cares ? Would you need to handle it as an integer ? Only in cases you care about certain property of ints e.g. comparison.
What I personally miss in bash are more decent datastructures — there are arrays and assoc arrays — but nothing beyond. I'd guess decent parsing of numbers in shell with actual error handling would be enough for me, also some assert e.g. 'this must be number' — I would not need full type system and type checking in shell.

As for IPC, I'd hate json as protocol, because I hate json. I'd even be in favor of binary protocol, but IMHO anything with a fix structure it a trap. Text is retardedly simple to parse/extract, anything with sctructure becomes pain over time

by bsbsbs (guest), 23 May 2019 20:39
apostolis (guest) 21 May 2019 11:18
in discussion Hidden / Per page discussions » Type-safeness in Shell

What is the difference between a shell command and a function in a program?
The shell command has a text ui and a function does not. If we were to automate the creation of a ui for functions, then functions could take the role of commands. And an ui does not have to be text based.

by apostolis (guest), 21 May 2019 11:18
b15r (guest) 16 May 2019 06:30
in discussion Hidden / Per page discussions » The Politics of Age (the Young vs. the Old)

I am a bit torn on this.

While the general aging of the population is a very interesting way to think about it, I do think that a lot of young people are not for action on climate change because they have come to the conclusion that it is an important issue, but because that is what is socially acceptable and "in fashion" (ignoring, for arguments sake, whether it is the right thing to worry about or not).

What I am saying is that while age can definitely lead to conservatism and stagnant opinions (possibly a consequence of loss aversion, c.f. Status Quo Bias), it can also lead to a more nuanced understanding of issues and more independent thinking, simply because the person has a greater set of experiences and knowledge to draw from than when they were younger and think on larger timescales. The precise fact that something will not affect me ten years down the line might also lead to less selfish thinking, maybe?

Then again I don't know if that is just my perception fooling me, it might be that the distribution between well-reasoned and logically thought out political opinions vs. going with whatever is the currently socially acceptable position is roughly the same across age groups. I wonder if there's been any analysis into this.

by b15r (guest), 16 May 2019 06:30

I was thinking along the same lines. Some kind of database containing metadata about the executables: the arguments, the input format, the output format etc.

by martin_sustrikmartin_sustrik, 13 May 2019 18:12
Jarkko Hietaniemi (guest) 13 May 2019 14:26
in discussion Hidden / Per page discussions » Type-safeness in Shell

Also: studying the shell completion languages (zsh, bash) would probably be useful here.

by Jarkko Hietaniemi (guest), 13 May 2019 14:26
Jarkko Hietaniemi (guest) 13 May 2019 13:11
in discussion Hidden / Per page discussions » Type-safeness in Shell

The command line syntax (including the types and expectations) should be inspectable, without execution or participation of the tool itself. Embedded in the dwarf info, or equivalent?

by Jarkko Hietaniemi (guest), 13 May 2019 13:11
Peter Panski (guest) 13 May 2019 07:06
in discussion Hidden / Per page discussions » Type-safeness in Shell

Just imagine every command or tool you call within your script would accept and return/output JSON. That would reduce many common errors.

by Peter Panski (guest), 13 May 2019 07:06
Carl (guest) 12 May 2019 23:47
in discussion Hidden / Per page discussions » Type-safeness in Shell

You may be interested in the Oil Shell project. The fact that arrays and strings are poorly distinguished was a major motivation for the project as I understand it. http://www.oilshell.org/

by Carl (guest), 12 May 2019 23:47

It reminds me of a different idea implemented at an Australian university in the early 1990s.

They couldn't afford an OODBMS - they were still expensive at the time, so they implemented their own where each row was a Unix text file, each table was a directory, and queries were done with Unix shell commands.

Unbearably slow, missing key concepts like transactions and security, but sufficient to allow them to try out experimental ideas.

by Julian (guest), 12 May 2019 16:33
Nerijus (guest) 12 May 2019 15:46
in discussion Hidden / Per page discussions » Type-safeness in Shell

How about powershell?

by Nerijus (guest), 12 May 2019 15:46
Norswap (guest) 12 May 2019 14:02
in discussion Hidden / Per page discussions » Type-safeness in Shell

@Tom Package-deal fallacy.

by Norswap (guest), 12 May 2019 14:02
Tom Parker-Shemilt (guest) 12 May 2019 11:35
in discussion Hidden / Per page discussions » Type-safeness in Shell

It can be done, but sadly that way lies PowerShell

by Tom Parker-Shemilt (guest), 12 May 2019 11:35
kristallo (guest) 04 May 2019 18:34
in discussion Hidden / Per page discussions » On the Nature of Programming Languages

So, in the end, it seems the representation, the language features matter even if there's no human brain around to take advantage of them.

I would say the opposite, the representation only matters if there is a brain. As you said yourself, the computer doesn't prefer pure Haskell beauty over some COBOL spaghetti monster (if anything, it prefers COBOL, or better yet, assembler). It is the mind which is central to the language design, because if there were no programmers, there would be no need for programming languages. So you cannot really take the human brain out of the equation.

The situation is often different in cases where the brain isn't involved so much as in programming languages, so you can take it out of the equation. Take word embedding for example: it doesn't make much sense to humans, but that doesn't matter, because humans don't work with that representation. It works perfectly for computers and that's what matters in this case. So apparently there are two kinds of representations: the human-oriented, and the computer-oriented. Which one is a better fit depends on the specific problem at hand.

by kristallo (guest), 04 May 2019 18:34
kristallo (guest) 04 May 2019 17:04
in discussion Hidden / Per page discussions » Enclave Pattern

I am a bit late to the party but anyways… I was facing the same problem a while ago and although I ended up implementing it in a way that broke encapsulation, I also conceived a "proper" but a bit complicated way to do it. My hypothetical approach would be to have a private mapping (eg. a hash table / dictionary) inside the list, which would enable us to access the prev- and next-pointers for each person, ideally in cca. constant time (but ofc not quite constant, and even if so, still with bigger overhead). We could use pointer to the person as the key in the dictionary, and the value would be a simple struct containing the prev/next pointers, and maybe some other data that might be handy. This solution is of course not as efficient as yours, where you have real constant-time access, but in theory :) I like it because it keeps the responsibilities completely separated and doesn't require creating a "person with helper" via inheritance or aggregation for each container class.

by kristallo (guest), 04 May 2019 17:04

There are definitely challenges and integrating with existing pipe-based programs seems to be the most daunting of them.

That being said, the hardware has changed since 1970, we have much more memory and much more disk nowadays and thus a large subset of the use cases can be solved by simply getting the entire output of the binary and saving it to a file (ls, grep and such).

What remains is a.) handling very large datasets b.) handling binaries with infinite output (e.g. yes).

As for a.) I am not sure that shell-like language is the good option for this kind of stuff in the first place.

As for b.) these can dealt with as a process running in a background and a named pipe. That will, if course, break once you restart the system, but until then it'll work.

by martin_sustrikmartin_sustrik, 04 May 2019 04:49

Cool idea, and could be expanded into other areas like first-class functions or continuations. Unfortunately, not all state can be saved into the todo / nextframe files, so you have to make some (considerable) sacrifices. It starts getting more complicated when you think about executing other code (eg. native binaries) which for a shell is a pretty common task.

Note how the "for" construct deleted the first element of "b". This may or may not be a good idea, but it's simple, so let's go with it for now.

I imagine it wouldn't be difficult to create a pointer into the list in scope of the for-loop. This pointer could for example be a file containing the name of the sequence and index, eg. b and 1. This way you could preserve b in its original form and use it in the loop. But then we run into other sorts of complications, and after giving it some thought it seems that maybe the right way to do it would be to translate the Pythonic for i in b into a more low-level while-loop with incrementing index and access the elements of b using this index.

Here we are getting into the area of CSP, goroutines and channels.

This is where it gets interesting. If the underlying system supports sockets or named pipes, this could help with IPC (shared memory / mutual exclusion / synchronization, select and so on), but again, as with executing native binaries or other programs, you cannot properly preserve the state if you are using sockets or pipes. And more importantly, you will not be able to debug correctly — once you read the data from the shared object manually (during debugging), it's gone and will not be available to the program. All in all, I think you not only will not have time to implement this shell, but if you want it to do anything meaningful, you most likely won't be able to do it at all, at least not properly. But I suppose you know all the caveats…

by kristallo (guest), 03 May 2019 17:08
page 1123...next »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License