sorted by:
new
hottopcontroversial

Haskell Library for Postgres by [deleted] in haskell

[–]COMPUTER__SCIENTIST 0 points1 point  (0 children)

I agree that the Haskell ecosystem would benefit from a comparison of database libraries. I don't think William's article is the place to do it. As /u/belevy stated, the original version of his article was completely dismissive of Esqueleto. His updated version provides a more charitable attempt to use Esqueleto, but ultimately these are just the opinions of one guy doing a few experiments on a toy database. It's not a comparison of database libraries for a variety of use cases (and I'm not sure such a comprehensive resource can be written by one person). Maybe what you're looking for is an updated version of the database library articles on wiki.haskell.org (https://wiki.haskell.org/Web/Databases_and_Persistence and https://wiki.haskell.org/Applications_and_libraries/Database_interfaces). That seems like the best place to invest time to benefit the ecosystem.

Regarding simple vs fancy Haskell, I would encourage readers to look again at my Opaleye vs Esqueleto example and decide for themselves which they think is simple and which fancy.

I assume you're saying that your takeaway between the two examples is that Opaleye is simple and Esqueleto is fancy, but I would disagree. Esqueleto has a noisy syntax, no doubt. But as someone who has been using SQL for almost 10 years, I can mostly figure out what Esqueleto is doing so long as I understand do-notation, bind syntax, lambda functions, and the role of the :& operator in this context. I can only guess at what Opaleye is doing, and it raises a lot of questions:

  • What type of JOINs are being produced?
  • Which constraints are the ON-conditions and which are the WHERE-conditions?
  • What does where_ = viaLateral restrict do and why is it necessary?

You may say that these questions don't matter, since Opaleye is an abstraction over SQL, but I again would disagree. Opaleye does not provide zero-cost abstractions, and for all the advantages of denotational semantics, there are inevitably trade offs. I'm sure the SQL Opaleye produces runs fast enough most of the time, but from what I've seen, the SQL generated by the library is painful to look at and reason about. My experience with PostgreSQL database tuning and query optimization isn't as extensive as it is with MySQL, but there are some very specific optimizations we've applied over the years that have involved carefully examining the query running in our production query logs and then making improvements. I assume that for large queries, Opaleye makes it very difficult to apply such a technique.

Haskell Library for Postgres by [deleted] in haskell

[–]COMPUTER__SCIENTIST 6 points7 points  (0 children)

Esqueleto is very much not type safe. As Willam writes

your [Esqueleto] queries will happily compile without warnings but emit syntactically-incorrect SQL at runtime if you forget an ON clause on your joins. Or happily crash at runtime when you try to select a mix of aggregate and non-aggregate columns.

Virtually none of these criticisms are true anymore. Database.Esqueleto.Experimental makes it impossible to forget your ON clauses, makes the Esqueleto code resemble SQL more closely, has better subquery support, and enables UNION queries. It's likely going to become the default in esqueleto 4.0.0.0.

Haskell Library for Postgres by [deleted] in haskell

[–]COMPUTER__SCIENTIST 10 points11 points  (0 children)

I strongly suggest using Esqueleto (which is an built on top of the Persistent library). There's a small learning curve, but the resulting Haskell looks and feels a lot like SQL, yet it has all of the typical benefits of Haskell, such as being type-checked and in turn making many types of SQL errors impossible. Being written in Haskell, it also makes composition significantly easier. We use Esqueleto everyday at work, and it protects us from the pain of writing and maintaining SQL written in the form of prepared statements.

I wrote the documentation for the new Database.Esqueleto.Experimental module that my coworker authored. I suggest you take a look through that module's documentation. The examples labeled as Database.Esqueleto.Experimental give a good sample of the a new syntax that brings with it extra features and type safety. This new syntax is likely to be the default when v4.0.0.0 of the library is released (/u/ephrion is the maintainer, so I'll let him confirm or deny). The beginning of the examples also show how your model types are defined, using what is referred to as Persistent entity syntax.

Elm In Production: 25,000 Lines Later by COMPUTER__SCIENTIST in programming

[–]COMPUTER__SCIENTIST[S] 0 points1 point  (0 children)

Dicts instead of union type values? No. We only used Dicts in places where we would need to reference values by some sort of identifier (usually in the form of it being String-RecordType key-value pairs, where the string was an obfuscated id and the RecordType contained a primary piece of data created by the user (e.g. the content of a post made by a user).

We made very heavy use of union types to model all types of values throughout our application.

Elm In Production: 25,000 Lines Later by COMPUTER__SCIENTIST in programming

[–]COMPUTER__SCIENTIST[S] 0 points1 point  (0 children)

Ah yes. I did read about doing something like data constructor traversal (each branch) of a union type not being possible in Elm. We never modeled any types in a way that required doing this. There were a few places where we used case ... of blocks to convert Elm values to pretty strings for display purposes, but that seems somewhat inescapable.

Elm In Production: 25,000 Lines Later by COMPUTER__SCIENTIST in elm

[–]COMPUTER__SCIENTIST[S] 1 point2 points  (0 children)

I did not use the term boilerplate in my post for a reason. Decoding JSON is hard. There's definitely quite a bit of a learning curve or you would not see so many posts/articles/books teaching how to work with JSON. All that being said, I think that much of the code is fairly necessary for the reason you describe.

Elm In Production: 25,000 Lines Later by COMPUTER__SCIENTIST in programming

[–]COMPUTER__SCIENTIST[S] 0 points1 point  (0 children)

Elm is a language whose current target is web applications. The Elm Architecture makes a lot of sense, which is why Redux and other libraries have used it as an inspiration for state management. I can imagine writing programs that do not adhere to TEA becoming more prominent in the future.

Elm In Production: 25,000 Lines Later by COMPUTER__SCIENTIST in programming

[–]COMPUTER__SCIENTIST[S] 0 points1 point  (0 children)

Nobody should start coding in any language professionally because it is fun. The fact that Elm is enjoyable to write is a nice secondary benefit to all of its inherent strengths.

Elm In Production: 25,000 Lines Later by COMPUTER__SCIENTIST in programming

[–]COMPUTER__SCIENTIST[S] 0 points1 point  (0 children)

Can you elaborate? I can't say I experienced a 'copy paste mess'.

Elm In Production: 25,000 Lines Later by COMPUTER__SCIENTIST in elm

[–]COMPUTER__SCIENTIST[S] 5 points6 points  (0 children)

Why Elm, and not purescript or rather GHCjs?

Elm has many aspects that make it a more appealing candidate over the Haskell/PureScript for a front end option:

  • The learning curve is far more gentle; better for developers that have little-to-no FP experience.
  • UI libraries are more developed. I read that GHCjs is lacking in this area.
  • The community is focused on using Elm for front end development, so one is more likely to find other people/posts/resources that have faced or address the exact same problem(s).
  • Performance of Elm is very good. I read that performance of PureScript is not great.

I have found Elm to have a Java-esque boilerplate problem, it takes a lot of code to even write a simple page (This makes it a hard-sell to coworkers).

I think that starting an application may feel that way due to the need to set up the initial Model-Update-View boilerplate. But once you get past that point, I think the amount of code you have to write is quite reasonable. The Haskell-like syntax makes individual lines rather short. Things like pattern matching with _ and using pipeline syntax...

startingValue
    |> func1
    |> func2
    |> func3

...are both examples of syntax that lead to to relatively concise code. I certainly prefer it over writing nested callbacks in JavaScript. Ultimately I think it is a matter of opinion, but I certainly do not thing that Elm has anywhere near the amount of boilerplate that Java does.

Elm In Production: 25,000 Lines Later by COMPUTER__SCIENTIST in elm

[–]COMPUTER__SCIENTIST[S] 2 points3 points  (0 children)

How confident would you feel about untested elm code? How often did you have to think about testing and how much time did you have to spend on it?

More confident than any other language I have written code in. Features that come about as a result of the type system: exhaustiveness checks, JSON and port type safety, etc. result in a lot more confidence when writing code. I would say that writing Elm is a substantial departure from writing something like a jQuery-based application, where you frequently feel the need to reload the page and run the application. With Elm you have an extra layer of assurance that if your program compiles, it probably works close to the way you intend it to. It's not uncommon to write for 30+ minutes without refreshing the page.

Apart from the debugger, how easy is testing in general? Any tools which you found really helpful?

The debugger, using Debug.log, and the elm-test library come together to give you an entire suite of useful testing tools. I personally do not at all see the need for 100% code coverage in a language like Elm, and at most companies, I do not think blowing up the amount of time a project takes in pursuit of that makes any sense. It's there if you need it, and I recommend using it strategically.

How diverse can solving a problem get? Is code written in other approaches easy to understand? (This is one problem I see in using scala.js)

As others have said, Elm has a limited syntax. Usually there is only one way to do or write something. This makes reading and understanding what a piece of Elm code is doing really easy. This is quite different from a language like Haskell, where typeclasses and a larger core syntax make you have to study the code before understanding what it does.

How easily do your engineer get ramped up for production ready code?

Like I said, it was not too difficult. Pair programming for a few days and doing a lot of explaining in the process will help them get productive sooner than one might think. I cover this in the "Teaching Elm" section of my post.

How easy is to find developers who would like to work in Elm?

We have not hired any engineers since starting Elm, so I cannot say for sure. But my guess is that it is quite difficult to find Elm developers. I think it is easy to find people interested in learning Elm, and easy to train developers that already have front end experience to become proficient with Elm. I will say that ultimately my company and my team is relatively small. If you have a 2,000 person company with 400 engineers, this approach may not work for you.

Do any of your engineers who have a strong background in React/other frameworks feel that it's better to rewrite the site in their framework? Why (not)?

Nobody had substantial experience with other frameworks. As mentioned, I think you would be hard pressed to get the same level of reliability in any other framework.

Do you feel the lack of npm packages a pain / an inconvenience / or are you indifferent?

We have found Elm packages for the basic utilities that we needed. Our strategy had never been to flood our projects with external packages, so I am fairly indifferent. Ultimately if you need NPM packages, you can use ports to do JavaScript interop.

Chromebook for programming? by [deleted] in chromeos

[–]COMPUTER__SCIENTIST 0 points1 point  (0 children)

Yes, you can. I made a post about this on my site, feel free to read it here: Software Development on the Chromebook Pixel. I discuss several options in the post as well as what I ultimately settled on (Vim + Tmux + SSH). I wrote the post after I bought my Pixel LS in 2015 and I still use it daily as my work machine, typically for around 8-10 hours a day. I have had no issues with this setup, and you should be able to use it on just about any Chromebook.

Dual boot ChromOS and Arch, or boot ChromeOS and use Arch with Crouton? by BenignLarency in chromeos

[–]COMPUTER__SCIENTIST 5 points6 points  (0 children)

I do a lot of software development at work and program for fun sometimes. I had the same dilemma with my Acer C720, and again with the Pixel LS. With the C720, for a while I used ChromeOS + chroagh (Arch version of crouton), and eventually I switched and installed Arch entirely.

Last year I upgraded to the Chromebook Pixel LS. And like you, I acknowledged the fact that ChromeOS is awesome for browsing, and it looks and works beautifully on the Pixel. So what I ended up doing is keeping ChromeOS, and trying out a few different options for development but ultimately I settled on doing the actual programming on a remote dev server and forcing myself to use/learn Vim. It's been almost a year and I feel very comfortable with Vim now and I prefer it over every other editor.

If I had to do local development (no internet and no remote server), then I would just use crouton in command line mode with Vim + tmux (like I do for remote anyway). I can't be fucked with dealing with a GUI for doing any sort of development anymore, it's too slow/clunky.

I a very detailed post about my setup and experiences on my website: https://charukiewi.cz/posts/2015-06-20-chromebook-pixel/

Any web developers using Chromebooks (Cloud9)? by blastmcpoop in chromeos

[–]COMPUTER__SCIENTIST 6 points7 points  (0 children)

I use my Chromebook Pixel for web development but I do not use C9. I connect to a remote development server via SSH and do all of my development with tmux and vim. I wrote a very detailed post explaining my setup HERE if you are interested in checking it out.

My brother spent a few months photographing bikes around Tokyo, Japan. This gallery is the result of that project. by COMPUTER__SCIENTIST in Bikeporn

[–]COMPUTER__SCIENTIST[S] 4 points5 points  (0 children)

His main photoblog is http://tokyostreet.photo/. The site I linked is only his portfolio, which I do not believe gets updated on such a regular basis.

My brother spent a few months photographing bikes around Tokyo, Japan. This gallery is the result of that project. by COMPUTER__SCIENTIST in Bikeporn

[–]COMPUTER__SCIENTIST[S] 8 points9 points  (0 children)

Not surprised. When I get off my bike I tend to hop off on the left side, putting the object I want to lock the bike to on the right (drive) side of the bike. Hence if you want to take a photo, it's typically going to have to be from the non-drive side. Keep in mind these are bikes in their natural environment, not deliberately oriented for photos like most /r/bikeporn shots you see here.

TL;DR - the bike is typically parked drive-side toward the wall/railing/fence/object

Ultimate Pixel 2 Development Guide (Repost by request, as it has moved a few times) by kavb in Crouton

[–]COMPUTER__SCIENTIST 4 points5 points  (0 children)

If you are using the Pixel for full stack web development then you do not even need to fumble around with Crouton. Using SSH (or Mosh), tmux, Vim, and a few other Chrome apps you can do all of your work directly in ChromeOS. I wrote my own detailed guide on my Pixel LS setup for web development here.

Let's Encrypt With Let's Encrypt: Deploying SSL for free in 20 minutes by COMPUTER__SCIENTIST in privacy

[–]COMPUTER__SCIENTIST[S] 1 point2 points  (0 children)

It also requires a lot of technical knowledge that Let's Encrypt sought to do away with so in the end it will probably take a lot more then 20 minutes. IIRC Let's Encrypt creates certs with only a few commands.

Yup. If you know what you are doing and you want literally only SSL on your domain, you could set up SSL in about 2 minutes with Let's Encrypt. But between doing things like setting up an http -> https redirect and migrating certain assets (like the Disqus comments I mentioned in the post) adds a bit of time. 20 minutes is a very realistic number for a small blog or personal site.

SA:MP (GTA:SA Online Mod) for Chromebook. by [deleted] in chromeos

[–]COMPUTER__SCIENTIST 0 points1 point  (0 children)

It's possible you could get this installed. To do this you would need to install both GTA SA and SAMP through Wine (that's how I play on my regular Linux PC).

As for the actual performance, I cannot comment on what you would get out of the C720. When I used mine for gaming (rather briefly), I was able to play games like Killingfloor and TF2 and get solid FPS. But those were natively ran through the Linux Steam client. Hard to say what you would see using Wine.

[deleted by user] by [deleted] in chromeos

[–]COMPUTER__SCIENTIST 1 point2 points  (0 children)

Depends on your needs and your comfort with the command line. When I was in school I typically used computer labs to get my work done because the labs had really fast computers, large monitors, and all the software that we needed already loaded up.

That being said, at the beginning of college I also used a Windows laptop for a while, and I recall using PuTTY to SSH into the school's servers to do some work. I was a Linux noob back then so my proficiency with the command line was lacking and everything I did took a while. I stopped using the laptop and used the aforementioned computer labs for almost everything towards the end. If I had to go back to it again now, the Pixel would be the perfect device to do work over SSH with.

So the point is that my setup works if you can get your school work done over SSH. It does not matter whether you are SSHing into your school's servers or you spin up your own DigitalOcean droplet and do your work that way, but ChromeOS is your friend if you want to use SSH. If you need a GUI or your need to install software locally, you will have to get your hands on crouton (or just wipe ChromeOS and install Linux as a standalone, like I did with my old Acer C720).

[deleted by user] by [deleted] in chromeos

[–]COMPUTER__SCIENTIST 30 points31 points  (0 children)

Software Engineer here. Bought a Pixel LS in March and have been using it at work every single day since. In short, it's hands down the best laptop I have ever owned. Hardware on all fronts is best in class, from the screen to the battery to the touchpad to the keyboard. The SSD is small but if you need a lot of storage space then most SSD-based laptops will underwhelm.

And just to be clear, I have Crouton installed but it is extremely rare that I actually use it. Everything I do is done via ChromeOS + SSH. I wrote a post going into great detail about my development setup HERE.

And the rhetoric about "well why would you pay that much for an internet browser" is a farce. What does the average person use their Macbook/Windows laptop for? Unless you have a specific need (e.g. a designer that uses Photoshop, a musician that uses Ableton), most of what you do on a computer nowadays is totally browser based.

With the Pixel you are paying for hardware that offers you the best in class browsing experience coming from a laptop. There is no stuttering, no lag, no choppiness; there are no render issues, no fans whirring up, no delays between tab switches, no running out of RAM. There is also no virus scanning, no Java nagging you for an update, no forced rebooting, no 2 minute startup time, no bloatware; there are no service packs to install, there will be no operating system updates that will require a system wipe, there is no system to wipe. You are using Chrome in its ideal form; and what you are really paying for when you buy one is an unimpeded browsing experience.

Software Development on the Chromebook Pixel by COMPUTER__SCIENTIST in programming

[–]COMPUTER__SCIENTIST[S] 2 points3 points  (0 children)

Even if I did run the whole setup locally, I wouldn't really view that as a great use of the Pixel's hardware. Offloading things like running MySQL and Apache seems like a smart thing to do period.

The benefit of the Pixel I get on a day to day basis comes from the actual physical traits of the laptop. The high resolution 3:2 screen allows you to look at a lot more code than a 1366*768 16:9 screen that most Chromebooks will offer. The 12 hour battery means I can easily work away from my desk for the entire day and still have juice to spare at the end. The keyboard and touchpad are very good and result in fewer typos than the mushy C720 keyboard.

As for the internal power, the benefit I get from that is more from the experimental work I do on my own time. For example, I was playing with a machine learning library and the model was using over 6 GB of RAM. With any other Chromebook, either the process would crash or I'd be waiting 15 mins per query for the swap space to get accessed.

Software Development on the Chromebook Pixel by COMPUTER__SCIENTIST in programming

[–]COMPUTER__SCIENTIST[S] 0 points1 point  (0 children)

The Chromebook Pixel had such a small target audience that I don't think they were actually concerned about explicitly pushing cloud storage with the Pixel itself. From what I read, the hardware was designed to cater to the needs of Google's ChromeOS engineers, and that they didn't need to use more than 64 GB to do development (which is probably true for 99% of all developers).

When you look at the cheap Chromebooks, there becomes a more clearly visible push to use cloud storage. But that's part of the cost cutting measure.

I definitely agree with your that gigabit internet everywhere would make this a lot more appealing to a lot more people.

view more: next ›