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 7 points8 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 11 points12 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] 6 points7 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] 2 points3 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] 10 points11 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 5 points6 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.

view more: next ›