Some fuddy-duddies think that preferring expression over safety is irresponsible. They might be right, but Perl is a language that doesn't have to justify itself:
Young Canadian here. Personally, it's just hard to find work, and there's no cheaper place than mom's house. My girlfriend lives with her parents. She has a job, but her family is having a hard time finding work themselves.
I'm doing it because it's free, and it's a chance to find a job. If I had a steady job, I'd be out in no time. But goings are tough.
I'm saying job a lot. Live in rural Canada and you'll find that job is the magic word. Lots of people do contracting work up here, for welding and scaffolding and that sort of thing. Lots of people have known the experience of working for a month and never seeing the paycheck as the company goes under.
There's a lot of fuss about the Cite C dam in British Columbia. I think it will be built, no matter the problems, because it means work for the people building it, and those people are people I know. Jobs jobs jobs.
I know this isn't about Canada, and I didn't even read the paywalled article, but I think we're staying home because the economy sucks and there are no jobs.
Basically, it's to make all OpenBSD developers participate in the release process. There's no dev and stable team - everyone is in the same tree, makes breaking changes early, spends months stabilizing. CVS helps force developers to participate, because branches can't exist for long before the resulting merge is too painful to be worth it.
Although, they are careful to say that, just because it works for them, doesn't mean it will work for you. As well, your other points are still valid. (My personal gripe is that CVS over the net is so slow that I have to use an external tool like CVSync.)
I wonder what about this made this difficult. Was it because it's a language interpreter? Libraries have this problem sometimes, but not as much. (I never hear of issues with gstreamer between 0.10 and 1.0, for example.) Maybe it was just that a binary called python existed? Maybe we should have just said "screw it, python means python2, end of story."
It's pretty simple - freedom 0 is the freedom to run the program as you wish, for any purpose. That includes in a proprietary environment. That includes whatever you want it to include. The other three freedoms then tell you "except in some ways we personally don't like."
They also don't like the FSF much. They have done some things that are a little controversial, like require devs to cede ownership of code so that the FSF can relicense when they want to (mostly to new versions of the GPL).
Obsolete is a funny word to use. In this case, it would mean that Python 2 is in good working order, but is no longer wanted. That's bound for a flame war, because:
- There is a community that wants it (largely enterprise).
- The Python team does not want it.
A less controversial word is deprecated - the Python team is discouraging use of Python 2, but not prohibiting it's use or development. That's fair, and if you read this page:
they are not very opinionated about it, largely saying "Use 3, unless you can't, then use 2 and start trying to migrate, unless you can't, then just use 2."
I will say, not to give somebody a bad day but, 2.8 seems like a bad idea. Currently python's development has still largely been a straight line, which is good for transitioning, but 2.8 would cause a fork. It would give a lot of people a short-term win for a long-term lose. Better not to tempt people.
I think this is a good idea. I realize that, you know, freedom of speech and all, but this is called HACKER NEWS.
I would personally like it best if the political news just lessened overall, rather than stopping entirely for a week, but what can you do. Can't just tell people "actually, the political thermometer is at 25°C, gotta let it cool down to 21°C."
This post is way too angry. The problem it describes is legitimate, but still just a problem to be fixed.
Having the language maintainer need to bless packages with native bindings is strange, though. Tag the packages so that people know they use native bindings, then people can decide whether or not to trust them. You cannot build an ecosystem through one person.
I really liked it! Then again, I played the games it was (obviously) inspired by, and I liked those games too. I understand if people don't like it - it's pretty personal, in the way that it's targeted directly towards the niche the creators love. Those things tend to be rather splitting, so it's unsurprising, in retrospect.
It's kind of like bad shark movies - there is a group of people who love them, and everyone else is fine not being in that group. It's not that either group is better or worse, it's just a niche.
It is indeed good! (I actually have the soundtrack on my phone.) But I suggest playing the game and letting the soundtrack surprise you. It really is worth a play.
A master programmer passed a novice programmer one day. The master noted the novice's preoccupation with a hand-held computer game. "Excuse me," he said, "may I examine it?"
The novice bolted to attention and handed the device to the master. "I see that the device claims to have three levels of play: Easy, Medium, and Hard," said the master. "Yet every such device has another level of play, where the device seeks not to conquer the human, nor to be conquered by the human."
"Pray, great master," implored the novice, "how does one find this mysterious setting?"
The master dropped the device to the ground and crushed it underfoot. And suddenly the novice was enlightened.
I've played video games since before I could walk. Some games I connect with and can't stop playing - Undertale and Papers Please come to mind. Most don't anymore, not even an old favorite like Doom.
I feel like there's something to this article, but I think it's larger than "I don't like Game of Thrones". There is room for games that really dig into humanity, rather than being meaningless mechanics.
Maturity: Perl 6 was released a little under a year ago. That's not long, and the leading implementation has not yet caught up with the standard (though work is ongoing). The ecosystem isn't quite there yet either.
Examples: People can be really bad at imagining value in the right things - they need to see it. There hasn't been a very compelling killer app yet.
Perception: People conflate Perl 6 with Perl 5. (Reasonably!) Most people remember TIMTOWTDI and remember that it was a bad thing, or at least that they prefer the Zen of Python. Most of all, they remember trying to read bad code. I don't think that Perl encourages bad code, but it sat in spaces that had lots of bad code already. (Lots of code made by people who are not programmers.) There are also codebases in Perl that are very well made, and easy to read. But we are better at remembering bad things.
Again, IMO, Perl 5's biggest problem was the surprising language. I could write something that was legal code, but had different semantic value than I thought, and the language was littered with cases like that. It was common to think that Perl was to complex for any one programmer to know.
Perl 6 isn't like this - the entire language is composed of simple components (at least, simple for their problem domains). It's also littered with good ideas that don't exist in other languages, like their regexen and grammar support. Everything else in the language is still top notch, like unicode handling and concurrency.
Basically, it is the things around the language, not the language itself. I think it is telling that people saying they don't want to use the language are saying "Perl sucks" rather than "I don't like feature X" or "This construct is confusing".
(I remember Eevee saying that "Perl 6 is truly the realization of Perl 5’s mission: to be startlingly consistent, and also just plain startling." I think that when people look at Perl 6, they'll be startled. But when they are no longer surprised, they'll just find powerful consistency.)
> POSIX was designed to be used on systems with comparable resources to what many embedded processors now have.
But not comparable environments. Most IOT environments are very small parts of very big systems, and POSIX defines a system with a teletype and a line editor.
I seriously doubt the value of the existing codebase. Saying code made for a server (like most existing unix code!) is fine for IOT feels wrong, and not just because IOT devices have kilobytes of memory and servers can have gigabytes/terabytes.
I don't think that a universal OS can work well when we know that universal programming languages, data transfer protocols, and everything else didn't. Imagine if we were still doing everything in PL/I. We recognize now that different programming tasks need different programming environments, but we still don't think that different programs need different program environments. It's just strange to me.
> would that, and thousands of other packages, be feasible without a workable POSIX layer?
I think my problem is the core concept. POSIX stands for Portable Operating System Interface (and X stands for Xtreme?). In an age where we spin up entire operating systems to start a single application, why are we defining portability at the operating system level when network portability works so much better?
Keep in mind, this is also an age where systems like Qubes OS can make separate VMs cooperate with each other.
The only sell for POSIX I can think of is performance, and I don't know if I buy it anymore. Why do programs have to be cross-compatible when the concept of an operating system no longer means owning the hardware?
I'm very excited about this! Minoca is an interesting system, and I applaud any attempt to make driver-writing less inherently horrible.
Minoca OS has been around for a while, but the news is that they're GPLv3. I think that's a great thing! The MIT license is good for software that wants to permeate through everything, but for building a community, the GPL is a good idea.
It seems that for any operating system to be successful, it has to carry around POSIX compatibility like an extremely expensive entry pass. I wonder when we will leave that behind? Or if we ever will? I'm glad POSIX is just a layer in Minoca, and not the base of the system, because these days it really should just be treated like a big wad of glue.
PS: I love the object manager. I don't see any particularly ground-breaking networking stack, though. A plan9-inspired networked file system approach would have been amazing, but it seems this project is content with today's more typical approach. Perhaps it is just trying to be less opinionated about network structure than plan9 was?
PPS: I'm terrible at organizing a comment. Maybe I need a blog.
I love your project! The of testing pervading the whole system is a very good one. I also like parameters being immutable unless they're a product, that's a great way of making passing references hurt less.
I still prefer the version Linus recommended. It's not for speed - I think it's more understandable. It's more simple (in the way Richard Hickey says, one strand rather than many) and there is less of it. Proving it correct would be easier, not that I actually would.
When people say "clever" to me, I think of code that is being tricky about something. (My canonical example of clever code is Duff's Device.) Linus' example doesn't read as tricky to me, it reads as very straightforward.
I'm reminded of a quote from Moore in "Thinking Forth":
"A lot of conditionals arise from fuzzy thinking about the problem. In servo-control theory, a lot of people think that the algorithm for the servo ought to be different when the distance is great than when it is close. Far away, you’re in slew mode; closer to the target you’re in decelerate mode; very close you’re in hunt mode. You have to test how far you are to know which algorithm to apply."
"I’ve worked out a non-linear servo-control algorithm that will handle full range. This approach eliminates the glitches at the transitioning points between one mode and the other. It eliminates the logic necessary to decide which algorithm to use. It eliminates your having to empirically determine the transition points. And of course, you have a much simpler program with one algorithm instead of three."
"Instead of trying to get rid of conditionals, you’re best to question the underlying theory that led to the conditionals."
That's part of a chapter of the book called Minimizing Control Structures. Forth guys are crazy about taste, and if I've learned anything from reading their stuff, it's that chasing tasteful programming to its end gets very hard.
OP is right on the money. The hard thing is that it is a creative process, and takes a real understanding of the problem you're solving to do it. Worst of all, aside from the feeling of solving a puzzle well, the benefits only begin appearing much later. I'm glad the kernel team takes it seriously.
I've never met Pieter, but I have enormous respect for him. His writing is some of the most insightful there is, and it changed my thinking on a lot of things, especially outside of computer science.
He finished his book Confessions of a Necromancer recently. It's well worth a read:
Boy, it's fast. I open a document, and it's there in less than a second. Very impressed. Like with Firefox, I'm starting to see the backend work.