If anyone feels like supporting this project, but doesn't think they'd actually use such a device, let me know, I'd happily accept one to test / use / etc.
1,083 karma · joined August 12, 2012
If anyone feels like supporting this project, but doesn't think they'd actually use such a device, let me know, I'd happily accept one to test / use / etc.
Haskell restricts what you can do hugely. But also lets you accomplish a whole lot within what it thinks of as safety.
I like Haskell - but think it's really just a playground for trying how far functional purity can be pushed, rather than being the actual best version of that paradigm.
Probably in 10-20 years time there will be a language around which takes all those concepts and comes together as a really pleasant unsurprising friendly developer experience. Maybe it'll come from slow evolution of Haskell... stack helps a lot, and a whole bunch of GHC extensions... but it's still got a lot of very impractical elements and hangovers from the past that really need to go.
This is a point release that they don't need to do - on the grounds that it's not a bad time to do one, but it should help in the future to do point releases quickly if there is a real need to (security, etc).
There's a commitment in the rust team to making life really really good for developers, and I appreciate that a lot.
My own experience was in writing a lot of vanilla JS, being pretty happy with it, and then wanting to grow bigger I investigated some of the frameworks. At the time, Angular 1.x was considered the thing, so I implemented a project in that (multiple drag and drop lists, items from lists into other lists, and so on), and tried to follow best practices as far as I could tell. DRY, decoupling, etc. It was pretty horrendous. I ended up with so many different services, service providers, components, dependency injectors, and all kinds of (to me) really quite complex abstract boilerplate that had nothing to do with the actual business problems.
I eventually got it all working, and thought I was doing pretty good. I then took a break from that project and came back to it 2 months later, and couldn't make head nor tail of it. So many angular-specific concepts and terminologies.
I've since come across mithril.js, and found it (for me) perfect. It's designed to let you build stuff really fast, and modularise things around your business logic, rather than have the whole of you application design enforced from the framework. Leo's blog posts https://lhorie.github.io/mithril-blog/ are fantastic, and I think made me understand a lot more of javascript itself, and how to design applications in much more 'well designed, but not framework specific' ways.
I, and probably many others, provide hosting for a few wordpress sites that we admin, and a client has only editor access to.
The way I've got it set up is:
- nginx running as nginx:nginx, handling static files, and passing on to PHP-fpm only for non-upload directories. - each site directory is owned by $clientname:$clientgroup. - php-fpm runs in each dir as $clientname-php:$clientgroup.
So wp-config.php, etc. configuration stuff is readable only by the group, and only writable by the owner user.
The PHP running user can upload media, post new content, but cannot upload plugins, edit any other PHP files, change any site-level configuration, etc.
To upload plugins, or do updates, inside wordpress it asks the user each time for a FTP username/password, which it uses to create a local ftp connection in to the server, as $clientname, which can then write to the plugins directory. FTP is only accessable from localhost, so there's nothing in plaintext on the wire.
Wordpress and plugin updates are done by WP-CLI hourly as a cronjob by the $clientname user.
Each site has its own database, user, and all that too.
All of this is set up by ansible, so it takes me about 3 commands to create a new site from scratch, or 5 to provision it onto a new server.
I've got reasonably defaults set up in php-fpm, so basedir, maxupload, restrictions, and all that. And as much as possible restrictions in place by nginx as well.
I'm working on automatic SSL certs from letsencrypt, which is working on some sites now, which beats the self-signed ones I had before (log-in only to wp-admin by SSL).
It seems relatively good for me. The sites are fast, cheap, and for my clients (small businesses, friends, family, church(s), etc), perfectly adequate.
I understand the full stack, and can keep the very cheap VPS running in less than an hour or so a month.
In the future, I hope that there is something more self-contained and easy to deploy, perhaps like caddy[1].
I'm not a huge fan of wordpress... but it's everywhere, and enough people have heard of it / can do stuff with it. The bus factor is a lot lower than many alternatives.
But this for a daily browser and then firefox for heavyweight stuff looks cool.
Thanks!
It's a bit like the perl of web page JS for me. I wouldn't recommend writing a full complex application in it - although that is possible and by people who know what they're doing can be done cleanly and organised... but for super quick hackery, it's hard to beat.
It installed really smoothly, and was really quick and easy to set up for me, and my not-so-techy wife.
It installed the nvidia drivers when I asked it to without having to touch the commandline (there's a "drivers" or something like that tool in the system settings). I'd had some problems with them before on a pure debian install, so I was quite impressed.
In general, it was a pretty good experience. I'm thinking I may well switch over to fedora at home though. With my home machine I want something that just works, that I don't need to go faffing with config files any more. I have enough of that at work.
I've been reading about, playing with, and really enjoying perl6 since the christmas announcements.
The idea of a 'fun hackers language' really appeals. There's a lot of 'oh sweeeeeet!' moments. I still won't be using perl for any production projects / work stuff for a while, but as a fun out-of-hours playground, this really does look like a cool new language. I'm pretty excited by it.
Next, try using the python ast modules for taking 'real' python code, and turning it into an AST which you can then do stuff with. For instance, you could take a subset of python, and turn it into C, or Javascript, or whatever. This will be fun, but don't expect to be able to turn all python into those other languages, there's just WAAY too many edge cases, differences in scope, etc. But for a subset of the language, however much you choose to use, it's pretty fun.
In general, parsing syntax should be the LEAST complex issue in writing a programming language. Playing with the above ideas in Python will be a lot of fun and you'll learn a lot anyway.
Some resources to look for... writing a LISP in python:
which is EXCELLENT. as is the followup article.
Another fun look at how someone does parsing, etc. in Go is 'lexical parsing in Go': https://www.youtube.com/watch?v=HxaD_trXwRE which is also fascinating.
Good luck! Merry holiday hacking!
But yes, GUI apps would be pretty good in Go, if there was better library support. I totally agree.
I wasn't trying to say Go is a "scripting language"... Maybe that came across badly.
There's a lot of crossover from where 'scripting' merges into the 'real application' world. I had a bunch on bash scripts for writing large video projects to tapes, and synchronising projects on multiple workstations. I then wrote a very simple web app so that non-techies could control it too without the commandline. I then ended up writing a small job queue for that, and a few other bits to go along with it, some workstation monitoring, and so on. It's now a 3k lines small python application, with a few shell scripts underneath.
That domain, Go could work pretty well for too, I think.
Ruby is not a language that would ever be used for writing a web browser, Virtualmachine, OS kernel, or other high performance low-level software.
Nor is Go.
Rust is.
Ruby and Go are languages for writing servers, web apps, 'scripting', and high level stuff.
Rust has the interesting property that it may well be possible to write relatively sane higher-up-the-stack server software, in the land that Ruby and Go currently are popular, but it's not there yet.
If you want a replacement for Ruby, and don't want to use Go (for whatever reason), then I'd really advise asking "Why?", first.
If you want to learn and grow as a programmer, then learn a bunch of languages, and don't get too hung up on whether or nor they'll last. There's a good chance that in 20 years time we'll all be using something totally weird and different, so learning a bunch of different ways of working and learning to think in different terms from Ruby may be more use than any specific language. Learn Haskell, Rust, Racket, Erlang, Assembly, Forth, Ada, Fortran, C, D, Clojure and Scala, say.
If you want a very practical language for writing server stuff, quickly and without having to learn too much new stuff straight away, then maybe look at Elixir, Kotlin or Ceylon.
If you're happy with Ruby, then there's no real reason not to stick with it. It's a good language, and a lot of fun to use. (Elixir is superficially similar, if the aesthetic of Ruby code really appeals to you).
Rust should be pretty easy to write extensions for ruby in, so if you want to try branching out into Rust, for doing high performance / low-level stuff, then give that a go.
Yes, I realise that this is part of Android's broken security model.
But the Signal app also wants access to practically everything. Device & App History, Identity, Calendar, Contact, Location, SMS, Phone, Photos/Media/Files, Camera, Microphone, WiFi Connection info and Device ID and call info.
Call me paranoid, but making an app with all those permissions seems kind of the obvious place for backdoors and similar.
If there was a 'light' version of the app which only required access the internet, then I'd be much more likely to install and use it. (And maybe if I ended up trusting it, then later install add-ons / the full version later).
In the article the 'problem' code is:
if u && u.profile && u.profile.thumbnails && u.profiles.thumbnails.large
do_something_with(u.profiles.thumbnails.large)
fi
which repeats u 5 times, and the entire u.profiles.thumbnails.large twice!which would be replaced by only asking once.
even worse (although somewhat clearer, perhaps) is what I've occasionally seen:
if u
if u.profile
if u.profile.thumbnails
if u.profile.thumbnails.large
do_something_with(u.profile.thumbnails.large)
end
end
end
end
And even the super verbose version there still can raise exceptions when you get slightly mad data - say you decode some JSON which has u.profile.thumbnails as "null" (a string) rather than actually a null. asking if u.profile.thumbnails
will be true - but when you request u.profile.thumbnails.large, you blow up.You can achieve similar effects using only exceptions, but there's a good argument for using exceptions only for exceptional circumstances.
begin
do_something_with(u.profile.thumbnails.large)
rescue NoMethodError #or similar
# oh no!
end
which (alas) also will catch all noMethodErrors in do_something_with. So you then end up with begin
tmp = u.profile.thumbnails.large
rescue
tmp = nil
end
if tmp
do_something(tmp)
end
which is super ugly.I may have got details wrong - not being a rubyist, but I think this is the general gist of where a nestable operator makes much much cleaner code, which catches more errors.
But guys - using a laptop at a standing desk is ergonomically still awful! If you look at the dude's neck angle in the photos, that is not a healthy way to be working all day.
Just because you're standing up doesn't mean you're exempt from regular 'keep monitors at eye level, head balanced nicely, arms and shoulders relaxed, etc' advice.
[1] http://www.amazon.co.uk/gp/product/B00SRV9UGE/ref=as_li_tl?i...
That said, given that python 2.7 is being continued to be maintained - but not with new features - for such a long time, and letting python 3 evolve quite quickly until it's now actually beginning (finally, around 3.5ish) to have features which are really appealing to many users (the async stuff, type hinting, etc), I don't think they've done too badly.
They could have made it quicker to happen, but since python2.7 is still a very good language, and works stably on practially every OS you could want, why try to force a change until people are ready?
People bitch about it [the changeover] a lot - not because it's terrible, but because it's lasting such a long time.
AFAIK, NO mainstream OS is shipping python3 as the main python, or even as a default installed python, yet.
Most big libs work in python3 now.
I reckon in 5 years time python3 should be the default install, with 2.7 as the legacy extra package for people who need it.
One way that could have been helpful (and may even be possible?????) would be a -2k flag for python3 which runs in python2.7 compatibility mode, or something. I dunno.
(j/k!)
Train tickets now are often more than the cost of petrol to drive across the country. So if you'd spend more on a train ticket, why not drive?
Sometimes it even cheaper to get a flight from Glasgow to London than it is to get the train.
To get a ticket, a week in advance, to go from Carlisle (where I live) to London costs roughly 120 pounds (that's 180 USD, ish).
It's crazy expensive, and the benefit really isn't there any more.
Goods wise, trains could / should have taken the same kind of approach that the shipping industry did, with containers.
If our company (live events A/V stuff, mainly) is doing an event down south, we should be able to call a train company, have them deliver a container (or pick up one that we own) at our warehouse on a flat bed truck, we load it, they take it to the train station, it get craned on, and then we minibus down there the next day and have it delivered to the location. But no, it's easier and cheaper for us to run our own bunch of trucks.
If there was a service like that, we'd use it.
I was meaning, in a sense, that it's better to have a language which doesn't have such a complex history, undefined behaviour, and weird syntactic trivia.
The simpler the language, the less unexpectedness occurs, and the more you can concentrate on the actual logic and meaning.
For instance, in English, "homosexual" = attracted sexually to those who are the same ("homo") gender as yourself. But "homophobic" does not mean hating/fearing those the same gender as yourself. The rules are complex, with history, weirdness, and are confusing.
The same with programming languages, I feel. Take JS, for instance.
>>> (0 == [])
true
>>> typeof (0 + 0)
"number"
>>> typeof ([] + [])
"string"
There is no reason on earth I want to know that stuff or operator precedence rules. I can never remember those if I need to do a `x * y + 2 z --` and so always write in brackets explicitly. But the language can accept such things, and make an order from them.Going back to C (sorry for jumping around), yes, it's simple compared to C++, or many other languages, but it does have a lot of history, undefined behaviour, and stuff you simply need to be aware of. And it's that stuff that makes life complex for C beginners (and allows bugs for C of all experience levels). There's a reason I didn't list C as a simple language. :-)
If our languages didn't have such quirks, and we didn't have to cope with working around them, a lot less mistakes would be made. http://separatedbyacommonlanguage.blogspot.co.uk/2007/10/to-... for instance, in English.
English - the Javascript of the human languages.
But to only understand 10% of a programming language's syntax seems a very limited understanding.
To only know 10% of the standard library or whatever is one thing... but 10% of syntax?
Either you don't know the language well at all, or else it must have a very complex syntax, with a lot of edge cases.
That's one of the nice things about (say) scheme, or lua, say. There's very little syntax to learn. Go, JS, Ruby and Python, more... but still, not that much syntax, really.
Even Ruby doesn't really have that much syntax to learn. Ruby, Python and Go all have pretty huge std libs, but not that much syntax.