451–460 of 525 posts
Earlier quoted context omitted.
The fact that Unix tools have trouble with spaces in filenames is absolutely a problem with Unix. If the Unix ecosystem had better support for this, then it wouldn't be a problem.
I don’t quite see how Unix tools have trouble with spaces in filenames. Could you detail some cases where the space handling is not due to the shell , as opposed to the program being invoked?
Earlier quoted context omitted.
> Make has deeply woven into it the assumption that the product of workflows are files, and that the way you can tell the state of a file is by its last modification date. I've always wondered whether Make would be seen as less of a grudging necessity, and more of an elegant panacea, if operating systems had gone the route of Plan 9, where everything is— symbolically —a file, even if it's not a file in the sense of "…
> everything is—symbolically—a file How are you going to make the result of a join in a relational database into a file, symbolically or otherwise?
dbjoin.done: database.db
sqlite3 $Earlier quoted context omitted.
So, go is also a "systems" language, so the terms more or less meaningless now. Assuming you mean a language we can easily compile to an independent binary capable of being run directly on a microprocessor with no support, I offer you rust as a counter-example. Also, functional programming and returning functions does not mean they are created at runtime.
It's a fact that C doesn't have closures. That is my point. I happen to like that fact, but you don't have to agree with me. And "creating functions" means: closing over variables ("closures"), or partial application. I think it takes at least that to be able to return interesting functions. (and whether go is a systems programming language is at least debatable. I think the creators have distanced themselves from th…
OK.
> That is my point.
Not unless your first two sentences have absolutely nothing to do with each other. Your point appears to be that because it's a low-level language it doesn't have these features, which is false.
> I happen to like that fact, but you don't have to agree with me.
Or I just think you don't have any experince using better languages. That isn't to say that other language could supplant C, but just that it's difficult for me to image actually liking the C type system (or lack thereof) and lack of first class functions. It's incredibly limiting and requires a lot of hoops to be jumped through to do anything interesting.
> And "creating functions" means: closing over variables ("closures"), or partial application.
Well, you said at runtime. Of course you can "create" functions at compile or programming time!
Earlier quoted context omitted.
Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches. I hate hearing people using 21st century or modern as…
> And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Users expect computers to work in a non-surprising ways. It isn't natural to use dashes or underscore in file names. Training users to be afraid of spaces is just teaching them one…
Developers are used to not using spaces: oneStupidClass or AnotherStillStupidClass or others_do_it_like_this or bIhatehungariannotation or daxpy .
As you can see it is not that bad and it has been a widely used practice for decades.
Since you are comparing specifically to windows land, perhaps it is their focus on using spaces in file names that made them always be worst than unix like systems in terms of stability, sequrity or performance.
Earlier quoted context omitted.
Wow if you consider Makefiles easy to read...
Simple makefiles couldn't be more simple. task: dependency list of commands That's about as easy as it gets.
Earlier quoted context omitted.
I don’t quite see how Unix tools have trouble with spaces in filenames. Could you detail some cases where the space handling is not due to the shell , as opposed to the program being invoked?
There's this program called make...
Why is it that each time a JS dev discovers something most other fields have been using for decades, it has to be "The Lost Art", "Superpower" ( https://medium.com/@wesharehoodies/typescript-javascript-wit... ) or something similarly tacky? There's no Lost Art, no superpowers. It's just the JS scene _finally_ slowly getting up to speed.
People learn things every day, acting like it's "slow" or you are better than them is a very toxic elitist point of view that is better off not said. You think your way of doing things is better, then you should encourage others to do it that way, don't put them down when they just start using it! I'm glad the ALGOL programmers of the 60's and 70's didn't spend their time laughing and putting down that new-fangled C language when it inevitably made some of the same mistakes.
And besides, very rarely is something in life a complete upgrade. Make is nice, but it has some very real pain-points (as evidenced by the handful of utilities that are makefile-generators, because getting make to do certain things or work on all platforms is so difficult). Gulp is great too, but it also has some very big issues in some areas. There is no universal "right" answer to any of this, and assuming that everyone that's not doing it your way just doesn't know any better isn't just naive, it's also wrong.
I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for use by humans. Since this is the 21st century, those files have spaces in their names. At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. A little searching reveals that the consensus on usi…
I was able to to it. Here's the source code "hello world.c": #include int main(void) { puts("Hello, world!"); return 0; } And here's the minimal Makefile to generate the output: hello world: Of course, I did have to swap out the ASCII SP (character 32) for the Unicode non-blank space (code 160) to get this to work, but hey, spaces!
How?
EDIT: Ok, now I got it. Boy that was a wild ride.
Earlier quoted context omitted.
JavaScript is in the server, browser, mobile apps, desktop apps and embedded devices. Basically, it’s used everywhere that C is used and then some.
> "Basically, it’s used everywhere that C is used and then some." It's the other way around. Every JavaScript program is run by a C/C++ program.
Earlier quoted context omitted.
It's a fact that C doesn't have closures. That is my point. I happen to like that fact, but you don't have to agree with me. And "creating functions" means: closing over variables ("closures"), or partial application. I think it takes at least that to be able to return interesting functions. (and whether go is a systems programming language is at least debatable. I think the creators have distanced themselves from th…
> It's a fact that C doesn't have closures. OK. > That is my point. Not unless your first two sentences have absolutely nothing to do with each other. Your point appears to be that because it's a low-level language it doesn't have these features, which is false. > I happen to like that fact, but you don't have to agree with me. Or I just think you don't have any experince using better languages. That isn't to say tha…
I would think that first class closures do indeed _not_ belong in a low-level language. They hide complexity, and you want to avoid that in low-level programming. Not necessarily for performance reasons, but more from a standpoint of clarity (which in turn can critically affect performance, but in subtler ways).
> Or I just think you don't have any experince using better languages.
Nah, I have experience in many other languages, including Python, C++11, Java, Haskell, Javascript, Postscript. The self-containment, control, robustness and clarity I get from a cleanly designed C architecture is just a lot more appealing to me. The only other language I can stand is Python, but for complex things, it becomes actually more work. For example, because it's so goddamn hard to just copy data as values in most languages (thanks to crazy object graphs).
> It's incredibly limiting and requires a lot of hoops to be jumped through to do anything interesting.
It depends on what you are doing. It's a bad match for domains where you have to fight with short-lived objects and do a lot of uncontrolled allocations and string conversions. My experience in other domains (including some types of enterprise software) is more the opposite, though. Most software projects written in more advanced languages are so damn complicated, but do nothing impressive at all. They are mostly busy fighting the complexity that comes from using the many features of the language. But those features help only a bit (in the small), and when you scale up they come back and bite you!
Here's a nice video from a guy who gets shit done, if you are interested: https://www.youtube.com/watch?v=khmFGThc5TI
> Well, you said at runtime. Of course you can "create" functions at compile or programming time!
Closures and partial application are done at runtime. The values bound are dynamic. So in that sense, the functions are indeed created at runtime. I sense that you were of the impression that a closure would actually have the argument "baked" in at compile time (resulting in a different code, at a low level) instead of the argument being applied at runtime. That's not the case, unless optimizations are possible. If that was really your impression, this makes my point regarding avoiding complexity and that closures do not belong in a low-level language. (Look up closure conversion / lambda lifting)