341–350 of 363 posts
When I look at a programming language, I look at the community and how it gets stuff done and projects that are noteworthy. Something about Haskell strikes me as different. Despite the buzz about it, I don't see many projects for it other than shellcheck, pandoc and xmonad, and for two of those, there's better solutions around (sphinx, awesome/i3). The other thing is the general flow I've see with Haskell programmers…
Earlier quoted context omitted.
The application described above is Java. Runs on Android and desktop Java with JavaFX. I tried to reimplement the desktop version with Go, due to native UI bindings. And failed.
Well, I don't see any problems with the logic part. Receiving, filtering, transforming, and notifying someone else about incoming messages (would probably do it in a few threads, sending messages between each other). For the UI part: no wonder, Go, at least currently, is useless for UI's.
The problem is that I try to abstract these things away – in Java, I have a general framework, and just do
var c = new ObservableCollection();
var f = new AsyncObservableFilter();
f.setSource(c);
f.addFilter(new DayChangeMessageFilter());
f.addFilter(new CollapseJoinLeaveMessageFilter());
f.addFilter(new RemoveIgnoredMessagesFilter());
var adapter = new ObservableAdapter();
adapter.setCollection(f.getResultCollection());
c.add(new Message(new Date(), "cube2222", "Well, I don't see any problems with the logic part."));
I’m using it with over 11 different types in the Java version, and I’d have to maintain 11 identical, but with different types, versions in the Go version.
You can understand how much of a pain in the ass this is.
Oh, btw, this also abstracts away the entire thread handling, while still doing it in a reasonable way.
And the backing collection doesn’t have to be a normal ObservableCollection storing data in memory – I also have ones using SQLite as backend, or caches, and I have the ability to add listeners for scrolling up or down to load or unload data as well, if it’s not needed anymore.
In Go, I’d manually have to reify all these, and if I find a bug in one, I’d have to update all of the others, too.
It is, I think, going to be very difficult to enjoy writing code in a less powerful language when you are exposed to languages that hold awesome power. In fact, this has been the basis for much writing on Lisp too. Paul Graham has written entire essays along the same lines. If you work in a job that forces the use of a less powerful language than what you've been exposed to, you can, I think, go through a sort of dep…
I don't know how to ask this without it sounding offensive, and I don't intend it that way. But do these "hardcore" haskellers enjoy writing programs at all? Like are there any well known open source apps that people actually use written in Haskell? There are tons of hobbiests and it has a following but what are the examples of its greatness? I ask as an old SML guy, I like the math theory, I like the promise of bett…
Earlier quoted context omitted.
You're right. If you have the freedom to choose the best tool, I think you absolutely should. I think the problem lies in the fact many programmers don't have the luxury of making those decisions. I imagine if one of those programmers refused to use the mandated tools, they'd get the sack. Many of those programmers, again, don't have the leg room to handle that. Plus, I don't think any employer would look favourably…
Counterpoint: Programmers don't choose the best language, they choose the language they are comfortable using. Source: at a previous job we had a "use whatever tool you want, just get the job done" policy. After two years we had everything from Perl to JavaScript in the same project. Edit: ... and this project was a desktop application!
bad programmers do that. As professionals, we should refuse to implement something in the wrong language and allow somebody else to do the job.
Earlier quoted context omitted.
I’ve actually never used any of them, and none of the devs or ops people I usually talk to used them either. We never even heard of any of those except for CockroachDB. Are you sure these are "dominating the entire industry"-products, as you mentioned before? Or is it more that they’re only used in SV?
In the ops world, these tools are pretty much the standard. If you look at the state of many of the tools targeted at infrastructure were, with in the best scenario a decently maintained Python code-base - it's no surprise the ops world jumped on Go. Go's main attraction there is that it's a simple, script-like language that compiles to easily deployed static binaries. That enables people who's main job is not necess…
Thankfully, this is true only in the HN bubble. One example: Amazon.
Earlier quoted context omitted.
I don't know how to ask this without it sounding offensive, and I don't intend it that way. But do these "hardcore" haskellers enjoy writing programs at all? Like are there any well known open source apps that people actually use written in Haskell? There are tons of hobbiests and it has a following but what are the examples of its greatness? I ask as an old SML guy, I like the math theory, I like the promise of bett…
Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there. The great thing about Haskell and other functional programming languages is that the functional style force…
Earlier quoted context omitted.
This is a fundamental misunderstanding of how go dependencies work. Dependencies are simply package names. It just happens that names are actually meaningful and tell you where you, the developer can get the package. Using vendoring and/or Godep/glide, you then strictly version and manage your dependencies. `go build` doesn't just run `git clone` or something.
So what is the approach when package X happens to change their Git path, change to another SCM server, or migrate the project to the next cool SCM tool? On any sensible package management system, as a user of the said package, I won't need to change anything.
Earlier quoted context omitted.
So what is the approach when package X happens to change their Git path, change to another SCM server, or migrate the project to the next cool SCM tool? On any sensible package management system, as a user of the said package, I won't need to change anything.
Vendoring is how you do dependency management with Go. Using vendoring you would also not need to change anything.
How you upgrade with zero code changes?
Earlier quoted context omitted.
Well, I don't see any problems with the logic part. Receiving, filtering, transforming, and notifying someone else about incoming messages (would probably do it in a few threads, sending messages between each other). For the UI part: no wonder, Go, at least currently, is useless for UI's.
> (would probably do it in a few threads, sending messages between each other). The problem is that I try to abstract these things away – in Java, I have a general framework, and just do var c = new ObservableCollection (); var f = new AsyncObservableFilter (); f.setSource(c); f.addFilter(new DayChangeMessageFilter()); f.addFilter(new CollapseJoinLeaveMessageFilter()); f.addFilter(new RemoveIgnoredMessagesFilter());…
If the genericism for you is also abstracting away the source of the messages -> in Go you just usually abstract sources as io.Readers.
All filters can easily be an intermediate channel which only sends further proper messages. Or just write a filter(func (m Message) bool) function which abstracts that away.
Though I understand you may want to use your Reactive collections and streams, this isn't really a case for Go.
Have I understood your use-case correctly?
Earlier quoted context omitted.
In the ops world, these tools are pretty much the standard. If you look at the state of many of the tools targeted at infrastructure were, with in the best scenario a decently maintained Python code-base - it's no surprise the ops world jumped on Go. Go's main attraction there is that it's a simple, script-like language that compiles to easily deployed static binaries. That enables people who's main job is not necess…
> In the ops world, these tools are pretty much the standard Thankfully, this is true only in the HN bubble. One example: Amazon.