HN user
You are getting downvoted, but there are obviously tens (hundreds??) of millions of people of faith--not just Christians--who would instantly reject any product with a demon as its mascot.
As a regular Linux/OSX/Windows user, here are the three (3) questions that I would need answered before switching:
1) In a world with Kali Linux, Arch, Red Hat, Ubuntu, Mint, Fedora, etc... what does FreeBSD give me that I don't already have?
2) In a world with OSX as a commercial Unix, what does FreeBSD give me that I don't already have?
3) In a world where virtually every desktop computer is Windows, what does FreeBSD give me that I don't already have?
If FreeBSD can't supply a good answer to those three questions, it's already lost.
I coded a simple, attractive Calorie Tracker that works across desktop, tablet, and mobile:
What resources did you use to figure out how to do that?
This is an interesting use of spreadsheets.
That's not a systematic bias. The senate was DESIGNED from the beginning to be immune to population differences: each state gets two senators, regardless of population. It was one of the compromises that convinced the small states to join the union in the first place.
Congress is limited to what it can legislate with the remainder defaulting back into the jurisdiction of the states as part of the Federalism system of checks and balances.
Check out Article 1 Section 8 of the United States Constitution, which enumerates the primary law-making jurisdictions of Congress.
Pace v Alabama was from 1883. Perez v Sharp was a California case from 1948--an odd case to cite since it had no controlling authority outside of California.
Regardless, Loving v Virginia (1967) was decided by unanimous decision--and that's back in the 60's--just three years after the passage of the Civil Rights Act. I don't know of anyone seriously suggesting that the holding in Loving is in jeopardy today; it's literally the direct application of the 14th Amendment.
Improvements in car seats would be my guess. Plus, vehicles were required by law to include special latches for anchoring car seats starting around the early 2000's. It was surprisingly tricky to properly install a car seat before those latches.
Figure 10-20 years for old cars to get swapped out for new ones and we're probably at a point now where most cars are equipped with those latches.
What was it like to use a BBS? In a word: awesome.
I was lucky enough to go to middle school in the late 80's with a kid who loved computers even more than I did and actually ran his own BBS on a 286 with a 20? megabyte hard drive. I asked my dad if he could bring home a modem from work. He delivered--I have a memory of 4800 baud, but that could be wrong). I dialed my friend's number and the rest was history.
The BBS experience consisted of three things:
First, trying to log in. A BBS was just somebody's computer attached to a private phone line. The more popular the BBS, the longer you had to wait until you connected. Luckily, ZModem had a redial feature. (Years later, my college would require us to call in to register for classes over the phone with long wait times and I used ZModem to auto-redial until I got in). Sysops would also limit users' time online to a set number of minutes to make sure everyone got a chance. The computer clocked your time. When your time ran out, the computer booted you and you couldn't log back in until 12:01 AM.
Second, the door games. Damn I miss those door games. You could log in and select from a whole host of games against other players. I lived for online Risk! God only knows how many games I played. I also played a little resource game called Space Dynasty and occasionally this other space 4X called Space Dominion or something that might have been programmed by the Sysop and his friend.
Third, the discussion boards. Think Hacker News, but with people from around town. Remember, they're locals because nobody wanted to pay the long distance fees. I actually met some of the people on the BBS. One of them even ran a competing BBS that I occasionally visited. People also played role playing games that way and conducted entire campaigns with strangers. Today, that's normal game play, but in 1988 it felt like stepping into a science fiction movie.
A good BBS honestly felt like a community. The identity you created for yourself mattered in those forums.
Good times!
I wanted one for the Forth environment too!
OLPC's Forth Tutorial: http://wiki.laptop.org/go/Forth_Lessons
You can overflow buffers all sorts of ways in C.
The Amish. No joke.
My dad's from there. The guy who lives next door to my grandparents drives a truck for the Amish since they can't.
Tax incentives. It's how we encourage a lot of good samaritan behavior.
Offer tax deductions for trees and watch forests pop up everywhere.
Your suggestion of parsing out the in-code documentation would go a long way towards documenting the libraries, provided the documentation is of high quality. However, that still doesn't address the bigger question: how do I program in Pharo.
There's a book, "On to Smalltalk" that actually did a decent job of getting you started, but it's decades out of date now.
Let me take these in reverse order...
Here is a link to Python's docs(https://docs.python.org/3/). It's still a little busy, but you can go a long way just by using the Python Tutorial (helpfully subtitled with 'start here') followed by the full Library Reference. A lot of people rave about how great Python is and how popular it's become, but I think one of the unsung heroes of Python's success has been the great documentation.
A (fairly) recent language that appears to have taken a page from Python's documentation success is Google Go. Here's the Go Docs:(https://golang.org/doc/) Take a look at that page. It describes Go, then tells you how to install it, then provides a pretty good tutorial (called a Tour of Go), and then provides a really comprehensive Reference Manual that tells you the various libraries Go ships with, which includes a hyperlink that reveals documentation for each library, and if you explore the linked page and click on a function, that's also a hyperlink that takes you to the actual code for that function so you can read the source code--itself is written in Go. Basically, it's easy to see how Go works, find out what libraries it includes, read good docs for each library, and even explore the library's implementation.
Continuing my argument, I would propose that many of the widely adopted languages of today aren't just good languages, but also benefitted from really good documentation. K&R is still famous, even though the last edition came out in 1989. Here's an interesting question: does C become such a big hit without the fantastic books it had? In the pre-WorldWideWeb universe in which C came to fruition, great books were critical. I would argue no. I believe it's documentation was a critical element of its success.
I think Perl has a similar story. Yes, it was powerful and useful and that was a big feather in its cap, but it also had amazing documentation in the form of books(Camel Book, Llama Book, O'Reilly Perl books in general) and man pages. It's easy to forget--and some don't even know about--the amazing man pages that Perl enjoyed. Here's a hyperlink to Perl's Man Pages table of contents: (http://perldoc.perl.org/perl.html) They are awesome! For example, check out the Perl regex tutorial man page: (http://perldoc.perl.org/perlretut.html) To this day, that's still probably the best explanation of regexes out there. And if that's too much, you can read Perl's quick and dirty regexes man page instead:(http://perldoc.perl.org/perlrequick.html) There's man pages for so much in Perl it's ridiculous.
(Rough waters ahead...)
Now back to your first question about Pharo's current docs. Here was my experience...
I checked out the links you posted. After a few clicks, I got a page with a bunch of pictures that looked like books. I'm wasn't sure what book I should pick, but "Pharo By Example," seemed promising. I clicked on it and discovered it's a PDF--not the preferred format for the web--that tells me the current version of Pharo is still Pharo 5. So I'm already worried because the book is out of date.
OK, I move forward to page 16 before I get to hello world. That's not too bad for a book, but slower than lots of web based tutorials, which is the real competition for "Pharo By Example" since I'm reading it on the web. Page after page then scroll by about Pharo the IDE, but not Pharo the language, which is what I'm really trying to learn about. Finally, on page 28, the book says we get to learn how to define a method, which is apparently how we do anything in Pharo, but then we crash to a stop and write a test first! Then we move forward again until we, at last, get our second piece of code: shout ^ self asUppercase,'!'
That extremely short method doesn't arrive until page 31.
Next we move to Chapter 3 and make a GUI game called LightsOut, which sounds cool, but it's like drinking from a fire hose because none of the syntax or libraries have been explained yet. (Note: At this point, I don't feel like I could run with this example to make games of my own.) If you survive Chapter 3, which is doubtful, and make it to Chapter 4 on page 59, the book finally explains Smalltalk syntax, though even this seems a bit jumbled since the real discussion of message syntax, which is at the core of Smalltalk syntax, is pushed back to Chapter 5 for some reason. Control structures are discussed in Chapter 4 instead. To put that into perspective, there's a mention of blocks serving as lexical closures in Chapter 4 before we really find out how basic messages work in Chapter 5.
By the end of Chapter 6, we've covered the Smalltalk object model and I still have no idea how to actually make a program! At least, I don't think I do.
To put it bluntly, "Pharo By Example" isn't a good programming book. Yes, I recognize it's a labor of love. Yes, I recognize that it's being given away for free. Yes, it took time to write. That's all noble. But it doesn't change the basic, ugly fact: "Pharo By Example" fails to get the job done.
At this point, I'm not at all confident that I will be able to program in Smalltalk after reading this book. More importantly, the book hasn't provided any real reason to become a Smalltalk programmer. It all looks a lot like IDE customization and tools for a language that doesn't seem to run anywhere except in the IDE itself. As an emacs user, I've already got one of those... :)
Seriously, I think some real thought needs to be put into explaining (1) why anyone would benefit from Smalltalk instead of more mainstream language and (2) how to showcase Smalltalk's strengths without getting lost in the weeds of the IDE.
Here's the curriculum that I suggest: (1) tell us how to download, install, and run Pharo (2) demonstrate how to build a few old school IO games--HiLO, Hammurapi, Trek, etc...--so we see how you can do IO. Along the way, introduce Pharo's syntax (3) give a full, long-winded, boring as hell discussion combining and improving upon Chapters 4-6 where you admit up front that it's going to be boring as hell and then (4) go back to saving stuff to Github and distributing the software. (5) explore the various parts of the IDE in independent chapters while providing real examples of how those features make our lives better. (6) go back and provide an entire section of webpages explaining, in great detail, the Morphic stuff that just gets a passing glance in the book for that LightsOut game. It really looks like there's something there, but who knows. That little chapter on Morphic in the back of the book doesn't remotely cut it. (7) provide separate chapters on important libraries? that Pharo comes bundled with--the kind of libraries that all modern languages take for granted and expect. (8) provide some real-world, well-commented, Pharo programs for us to dissect so we can see what they look like. For most languages, I can just download a few open source projects and read code until I'm sick of it. Does that even exist for Pharo?
Let me say again that I honestly think Pharo looks amazing. I really want to know how to make something in it, but I'm not sure I ever will because the amount of effort I'm describing is huge. I hope it happens though.
Finally, I recognize that my feedback was critical. I sincerely hope that you take it as constructive criticism rather than as an attempt to insult. The last thing I'm trying to do is insult anyone.
TLDR: Pharo needs mountains of high-quality documentation equal to Python's docs or Java's docs if it seriously hopes to attract server-side or desktop mindshare among developers.
Long Version:
In 1980, Smalltalk had some of the best documentation of any language out there. In 2019, it basically has none. By 2019 standards, Pharo 7 ships without any documentation at all. That's a game-stopper.
Pharo 7 looks really polished. It sounds like the design team put in tons of hard work over the past year and half to produce this release. Moreover, since it's smalltalk, Pharo is also probably very powerful for both web and desktop development. BUT NONE OF THAT MATTERS IF DEVELOPERS CAN'T FIGURE OUT HOW TO USE IT!!!
(pardon the all caps, but I want to emphasize my point)
Here is my message for the development team: if you really want developers to start building stuff with Pharo, then you absolutely must (1) write detailed, soup-to-nuts, high quality docs for web design and (2) write another set of detailed, soup-to-nuts, high quality docs for desktop GUI programming.
The Pharo book doesn't cut it--not even close. It's not a very good book. The Pharo MOOC doesn't cut it--again, not even close. Who wants to learn that way? ProfStef is just a fancy hello world; it's really not a tutorial and it doesn't lead anywhere.
I realize that what I'm saying comes across as pretty strong medicine, but please understand, that's because I actually think Pharo looks amazing and would like to use it.
In my opinion, you should stop development on Pharo and document what you've built instead. Write docs for a year. Today's release announcement states that the Pharo 7 team closed 2142 issues. Brag in 2020 about the fact that you wrote 2142 pages of documentation and tutorials over the past year. Make your documentation coverage as thorough as your testing coverage.
Imagine what might happen if Smalltalk 2020 was as thoroughly documented as Smalltalk 80.
I don't see anything in your response about success.
It's true that if you want credit for completing a major, then it is necessary for you to actually complete the major, but that still doesn't equate to graduating at or near the top of your class.
How in the world does "being compliant to authority" contribute to university success? What major emphasizes compliance over learning the material and doing the work?
This looks great! I have two questions: 1) Can you resize the notecards for easier management 2) Can you export to .docx for publication submission?
The page says last updated November 22, 2016...they might
How do you get started with GUI programming? I can't seem to find anything on this for Pharo6...and barely anything for earlier versions (which I'm assuming are now obsolete).
I believe it. If he owns everything free and clear--I'm betting he does--and he avoids big purchases and fancy trips, he can basically get by on purchasing nothing but food, electricity, phone, and gas. Tack on some clothes and reasonable eating out, and you can live well on $25,000 per year. Everything else was probably paid for by the team.
What's the explanation for the huge drop in sales? Those single engine airplanes are still around? Deregulation of the airlines has resulted in cheaper commercial air travel? More telecommuting? What?
I'm genuinely interested in the explanation.
For those who haven't seen it, Weird Al's song "It's All About The Pentiums" should be required Hacker News watching: https://youtu.be/qpMvS1Q1sos
Did you mean to reply to me? I ask because your comment appears to be disagreeing with arguments that I never made.
My major point was that (1)the coast, by itself, was not a critical factor either pro or con. (2) What appears to matter when it comes to becoming a first rate city is food production and access to trade, be it by road, river, or sea--preferably, all three.
Your defense thesis doesn't make sense. If defense really mattered, cities would be built on mountain tops, but they aren't. Instead, cities grow where trade flourishes. They take their lumps, periodically, from invasion, and then rebuild and get back to business. Virtually every major city from the ancient world is still in business, even though the empire that founded it has long since been destroyed. Only when the economic basis of the city gets destroyed, does the city die. That argues for economics trumping military considerations, which, again, was my thesis.
Finally, bombers don't appear to have altered this equation one bit. To the best of my knowledge, the major cities from before WWII are still major cities today.
The location of ancient capitals probably has more to do with the importance of trade and food production than avoiding coastal storms or flooding.
i.e. they would be wildly popular if they just didn't have any competition?
"I wish Perl would do an inplace edit of a file without creating a backup, though."
It's been a while, but I think the -i command line switch accomplishes what you want here.
What do the graphical environments gain you
Simplicity. In my IDE, I start it up and then program.
With emacs, it always felt like I spent a lot of time curating the editor. Part of that was because customizing emacs is fun--I have this big .emacs file that imports an even bigger .elisp file--but I also always seemed to be referring to some documentation because I'd forgotten that particular set of key-chords or messing with something to get it to work.
I've come to prefer simplicity. In fact, after years of using emacs, I switched to vim for the moments when I want to program on the command line. (I think my only customization in VIM is mapping jj to escape)
emacs & slime[1]
I've spent a lot of time with emacs, and slime was what I used when I was exploring Common Lisp: both SBCL and CLISP. Emacs is really powerful and I'm fairly at home with it, but I've come to prefer more graphical IDE's. Judging from the popularity of Eclipse, Visual Studio, NetBeans, etc...I'd say I'm not alone. Telling programmers it's emacs+slime or the highway is not a strength; it discourages everyone who prefers those other environments.
I'd even go as far as saying that targeting a specific implementation is usually a sign of bad coding style.
I was suggesting ABCL because it is a full implementation of CL on the JVM. If there are other CL's with ABCL's level of maturity on the JVM, then they would work just as well.
Beyond that, I imagine that many programming projects target specific implementations for various, pragmatic reasons.