Hacker News new | past | comments | ask | show | jobs | submit login
Native GUI library for Go (github.com)
220 points by scapbi on June 6, 2014 | hide | past | web | favorite | 108 comments



I'm interested in this because I'm cleaning up and restructuring LibreOffice's VCL (Visual Component Library) code. In terms of OO, it's a mess of tangled code. This might give me some ideas.


You brave soul. I hope you accomplish what you've started - LibreOffice GUI improvements, especially regarding the foundations, are greatly appreciated.

Would it be possible, long term, to use Qt? I mean switch the current components to be based on Qt and then, over time, actually start using Qt?


There's already an effort underway. LO has a fundamental classes when it comes to implementing the VCL: OutputDevice, SalGraphics, SalFrame and SalInstance. Mainly SalGraphics and OutputDevice though. The problem is it is so intertwined, the biggest issue being that classes don't follow the Single Responsibility Principle.

It's getting there, but I've only really done any real coding in anger in the last 5 months and this is a 25 year code base...


Please do it in D. C++ is horrible. But if you insist in C++, isn't nana an option?


Doing it in another language would probably require rewriting the entirety of LibreOffice, which is a very massive project with code spanning at least a decade, if not more. They recently switched away from a proprietary (in the sense that only they used it) build system to one of the more conventional ones (I forget from what to what), so anything IS possible, but the question is whether it would be worth it. I know LibreOffice has some Java interoperability, but I don't know how much, or whether that could be leveraged.


Oh... we are trying to get away from a dependency on Java :(

Nana looks interesting - I'm always looking at C++ toolkits to better understand how they work. I was looking at it's event system, seems pretty nice. gtkmm also has a nice signals system also.

But yes, rewriting in D would be more than complex. LO has over 7 million lines of code, the real issue is that there is still a lot of cruft (e.g. the Resource class, tools, etc) and we are progressively working on removing this and replacing with saner libraries, such as boost.

Interestingly, VCL actually works pretty much by itself. I recently resurrected some VCL demos and got them to work as standalone executables. VCL could actually be as clean to work with as nana, but the guts need a rewrite. And it would do it in a cross-platform way, but with largely native widgets.


An easier way of looking at the API:

http://godoc.org/github.com/andlabs/ui


Anyone had chance to try this yet? Is it any good?

I notice the Linux APIs call GTK which, while I can understand the logic of, I rather liked the Qt Go Bindings I played around with last year.


It is very rudimentary; all the basics are there, but there are some glaring things I couldn't figure out yet - like how to move the Window to a new screen position, things like that. Might be my ignorance though, I've only had 15 minutes of glance at it, and as I'm mostly interested in learning Go casually, maybe there's some things I've missed ..


It may have been done with Wayland in mind, where there is no client-side way of setting the window position, or even querying it, since wayland does not let the client know. The position of windows is managed entirely by the wayland server.


While I do have Wayland in mind, that's specifically for what I can do with the GTK+ backend when running against GTK+'s limits. For this particular feature, there's a different rationale, but I can't remember what it was right now. That being said, I may add such a thing in the future (there's something in futureplans.md about centering the window right now, so...).

And yes, this is still rather incomplete (I'm surprised it's getting so much attention this early!); please feel free to make suggestions!


Fair play. This is as good a project to learn Go with as any :)


With the caveats that I haven't used it yet, and that I don't know if it reflects actual product quality: after a skim, I can say the code itself is pretty messy. Randomly formatted, nonidiomatic naming conventions, lots of commented-out blocks and dead code, haphazardly organized.


What random formatting do you mean, other than what go fmt would produce? What unidiomatic naming conventions? I thought I removed all the dead code... which ones do you still see? What suggestions can you make about organization?


    > What random formatting?
Primarily here I saw a lot of arbitrary indentation. As far as I can tell, everything would be fixed by a gofmt -w...

https://github.com/andlabs/ui/blob/master/button.go#L16-19

https://github.com/andlabs/ui/blob/master/area_unix.go#L35-3...

https://github.com/andlabs/ui/blob/master/area_unix.go#L107

https://github.com/andlabs/ui/blob/master/area_unix.go#L200

https://github.com/andlabs/ui/blob/master/area_unix.go#L329-...

https://github.com/andlabs/ui/blob/master/grid.go#L18-26

    > What unidiomatic naming conventions?
Primarily here I saw a lot of underscores, which are never used in pure Go. Some of that maybe is due to Cgo conventions, but some of it isn't.

https://github.com/andlabs/ui/blob/master/area_unix.go#L209

https://github.com/andlabs/ui/blob/master/sysdata.go#L23


All indentation ones except the L35-37 ones are lack of go fmt. I will go fmt once I can double-check exactly what go fmt changes.

L35-37 I'm not sure what problem that has; I just put the very long bitmask on its own line.

The underscores in our_xxx_xxx_xxx I don't think would be much of an issue. They unintentionally match the GTK+ naming conventions. I don't know why I did them, but I don't consider it a world-ending issue worth fixing. Same for _xSysData, but in that case the _ is there in case I accidentally said xSysData somewhere else.


lines 9-16 of this file: https://github.com/andlabs/ui/blob/master/checkbox.go

or lines 10-12 of this file: https://github.com/andlabs/ui/blob/master/area_darwin.go

those were the first to files I picked.

I have no comment on organization--something I struggle with.


Are you sure the code in checkbox.go is commented out? That's not what I see.

As for area_darwin.go, though it's a comment, it's actually C code being sent to an FFI: http://tip.golang.org/cmd/cgo/


Don't sweat it too much. The first thing that happens whenever anyone publishes any Go code on the internet is a random commenter pops up and criticises it for being "unidiomatic".

I'm beginning to think that "idiomatic" is actually a portmanteau of "automatic" and "idiotic" because it's such a knee-jerk reaction in the community now.

If it's flaws in your variable naming and indentation, let it slide. If it's flaws in the logic or functionality, deal with it.


'idiomatic' is used as newspeak for 'not the style I personally recognize as being the true Go way'.


    > 'idiomatic' is used as newspeak for 'not the style I 
    > personally recognize as being the true Go way'.
There is, in fact, a style which is "the true Go way".


'idiomatic' is not an objective term, but people use it like if it were.

There's a true Go way, the style used in the stdlib; but even the stdlib is not consistent and you need to pick and choose. Then the standard library doesn't cover all possible cases.

My definition of idiomatic Go code is:

    1. It passes gofmt
    2. It passes govet
    3. It passes golint
    4. It checks it's errors.
    5. It looks like code in the stdlib.
    6. For the rest, it looks like code written by other 
       people that I recognize as being good Go developers.
    7. For the rest, it looks like my own code.
I think that's a stricter definition than what most people think of when they criticize code as being unidiomatic. However it's still very subjective. From 1 to 4 are objective measurements. Point 5 is somewhat subjective. Points 6 and 7 are simply a matter of my personal experience through life and how circumstances led me to encounter a specific subset of code; entirely subjective.


The definition of idiomatic Go code is go fmt, go vet, golint, and https://code.google.com/p/go-wiki/wiki/CodeReviewComments.


Looks like a decent effort at creating the basics - certainly usable for basic things like buttons and forms and such .. well, I appreciate the simplicity of this ui kit so far, as I'm currently learning Go. I'm enjoying learning what area_darwin.go/.m are doing .. toll-free bridge, k?

(wakeup doesn't run with the current version though, missing window w in args, but that's an easy fix..)

So from 10 minutes of looking at it and getting wakeup built, I've learned some new Go stuff. Thanks for that! :)


Although I'm skeptical about this project (as I usually am with widget platform-native toolkits like this), I'm very interested about how it turns out. It looks like it's in early development, but the author seems to know his stuff. It would have been really cool to see back when I was first trying Go out, but I've since lost interest in Go since they're taking so long to implement generics, and I'm not interested in copy/pasting so much code. When I'm writing OS X apps (I don't use any other platform these days), writing in Swift seems like a much more fun option (too bad it's not open source, yet).


Here's the kicker: you don't actually end up copy/pasting much code.


You shouldn't be copy/pasting ANY code in a language created after 2000.


It's a slippery slope ("oh it's fine, I'm only copy/pasting N file(s)" where N slowly increases) which I don't want to go down.


Can you think of 3 specific examples and quantify the fan-out?


1. Float64Slice

2. IntSlice

3. StringSlice

http://golang.org/pkg/sort/


Ah yes, I've run into this. It's certainly not some kind of "rabbit hole." So basically, there's a few lines of boilerplate for each time you want to sort something. So this is O(1) additional typing per sorted type, which is what it would be for generics. You're trying to kill your argument with faint support?

EDIT: Granted, it is an unusual formulation, and far less convenient.


1-A. SearchFloat64s

2-A. SearchInts

3-A. SearchStrings

http://golang.org/pkg/sort/


Ho hum. Same arguments apply. Also O(1) per type, just like generics.


I'm skeptical about the urgent need for generics. In over 3 decades of coding in some big corporate code bases, I've only seen situations where generics could have defended against really terrible coding practices. (This collection only ever has Portfolios in it. Why don't I stick a line item in there for my convenience?) But in that case, the shop has something more critical to worry about than choice of programming language.

Granted, there are some quite complex systems out there where generics could deliver truly valuable type safety. I doubt all the systems that are that complicated really need to be.

The likelihood that a programming language feature will be over/mis-used is directly proportional to how nifty it is.


I just know that generics are helpful. Not just a convenience, but genuinely helpful. And it gives a kind of help that can't easily be replaced by a new library or third party tools. Which, to me, makes generics a very welcome language addition. You could very well code big and small projects without them (and I have too). But that doesn't negate their utility.


Not just a convenience, but genuinely helpful.

Specifically, how?

EDIT: Surprisingly, programmers do a lot of this "just knowing." You'd think that a supposedly quantifiable field would have more, quantification. Going by "guts" is particularly bad in big enterprises, where decisions are often more about politics than about quantifiable results.


I can guess what he hints at. If you don't have generics, you either copy-paste-replace common data structures, or you implement them for the equivalent of void .

The former means more code. That can be hidden out of view, but it means more work when fixing bugs in that code, introduces subtle bugs when one forgets to apply a bug fix to a 'copy', and slows down compiles.

The latter means adding casts to your code that make it harder to read and (more code is buggier code) also runs the risk of introducing bugs.

The two-and-halfth option is to use some preprocessor to generate code variants for you. IMO, that is just a bad implementation of generics.

Yes, that is not quantified, but I think it covers the how* part.


Casting (for example) is a pain, but to me the best aspect of generics is the documentation they provide of the types involved with a given piece of code.


Objective-C doesn't have generics either and is/was the blessed API language on your chosen OS. The horror!


Obj-C is 31 years old. I don't think it's unreasonable to expect new languages/frameworks to have progressed in that time.


Isn't it normal to expect old languages to evolve too, especially when they are pushed forward by companies as huge as Apple? Look at C++ (the same age as Objective-C): C++11 was approved in 2011.


Swift, Apple's days-old intended replacement for Objective-C, does have generics.


Isn't it about time? I mean, they don't really have to make a brand new language to add generics.


As mentioned elsewhere, Objective-C is mostly dynamically typed, and you can just silently cast id to things, so it doesn't need generics as much as a language like Go, although they certainly could be useful. On the other hand, the dynamic typing makes it slow with generics or not, and if you want to put numbers in collections, you have to go through a very cumbersome boxing process - two of the many things only a new language could resolve.


It's also not statically typed - that's one of the things that generics can really help with.


Surprisingly, people have different expectations between a language from the 80s and a language less than a decade old.


And Objective-C isn't really strongly typed either, so you can send anything any message.


FWIW this is specifically why Objective-C has been able to get by without generics for a while. You don't get solid type-checking like you do with generics in other languages (except C++), but that has never really been an issue because the above statement works even with [...] statements (sure, the compiler will warn you, but).

The only real issue is that the things you shove into Objective-C containers must themselves be Objective-C types, which means using NSNumber and NSValue everywhere for raw C types. The new Objective-C @literal and @(expression) syntax, however, should make such code cleaner in the future...


Because it is dynamically typed, duh!


it's really shitty people were downvoting you for a relevant developer experience. You actually used Go, you found you kept duplicating code, and you feel this project might help. Some may theorize that you didn't quite drink the koolaid and are trying to make Java in Go or something, but the speculation is worthless, and the observation is valuable.

Your post is a good post.


I though GTK3 was available for Go. Why yet another library?


Existing GTK+ bindings require very recent versions of GTK+, which, while they provide some useful things, fail backwards-compatibility tests pretty hard, especially on distributions like Ubuntu. That being said, I do have a project in mind that will use jrick's gotk3 and GTK+ 3.10...

GTK+ on Windows doesn't really have a particularly good reputation among myself and some of the people I know, and I didn't know native GTK+ for Mac was a thing until very recently.


Though it's great to a see a new GUI library for Go, I'm wondering if it's following the best approach. Most frameworks seem to be moving towards more declarative languages (HTML for many platforms, QML for Qt), often mixed with JS, and it makes it much easier to create GUI. Not sure if we need another clone of wxWidgets/QtWidgets. I wonder if something like a native QML interpreter in Go would be possible.


Check this out: https://github.com/go-qml/qml

It's written by the same guy who made the awesome MongoDB driver for Go, so I have high hopes!


go-qml has already stirred up enough interest for that same guy to run a program-making contest at the recent GopherCon so I guess it's safe to say your hopes are reasonable =P



Is the readme supposed to look like that? The first few paragraphs are all 'h2' level text. Very difficult to read through.


I just replaced it with a detailed placeholder for now. (Replacing it was something I had stuck in the back of my mind for a while.)


Why do people hate images and videos so much? It's a GUI library! I skimmed the whole readme and have no idea what it looks like and found no link that would make me any smarter. Am I weird in this regard?


It's platform-native. It looks like your platform. What else do you need to know?


On Mac OS, it's extremely rare that 'platform-native' cross-platform GUI libraries actually 'look like your platform'. Most are subtly wrong, feel less usable, don't conform to platform guidelines, etc.

It's extremely rare to see a cross-platform GUI on OS X that doesn't feel like it's just a reskinned Windows or GTK+ app, which makes it cumbersome to use.


I wrote a cross-platform library that is the thinnest possible layer around Cocoa, and creates the actual Cocoa controls directly. They are truly 100% native widgets.

And yet, it's exactly like you say. It has nothing to do with the base widgets. The problem is that to look native on OS X, you have to use widgets that only exist on OS X, like their merged titlebar+toolbar that changes and resizes the entire window content used on preferences dialogs, or the blue left navigation sidepanel, or the big question mark button, or the segmented control, or the color selection popup menu with the wide color boxes in each list item, or the combo box zoom setting in one segment of the status bar.

And then your labels have to be right-justified while the controls are left-justified against those. You have to add about three times as much spacing between widgets as on other platforms. You have to have a single menubar that's outside the main window, and always has a "program name" menu where your preferences option has to be, a view menu, a window menu, and a help menu.

You have to be sure to tie in to all the OS X only things like AppleScript, Core(Image, Audio, ...), dialog sheets that slide down on a window and then are only modal to just that one window, etc. Your message boxes can't have titles anymore, but everywhere else expects one.

Even if you tried to add the extra spacing and hack in those OS X only widgets to Windows and Linux, then the Windows/Linux versions would be super hideous and unnatural. By the time you customize all of that, the code's a bigger mess than just making two separate GUIs. Defeats the entire purpose of using a cross-platform toolkit.

Bottom line is that Apple just does way too much stuff differently to be able to craft a cross-platform app that looks great everywhere with no platform-specific customizations.

And now Metro, Gnome 3, Unity and KDE 4/5 are trying to go in entirely different directions as well. And iOS and Android are big targets now, too. Sadly, the dream of write-once, run-anywhere and look nice is dead.


I keep hearing this kind of defeatism about cross-platform GUI items and it rubs me the wrong way. I mean, a unified menubar vs the separate mene/titlebar of Windows/Gnome is exactly the kind of thing I'd expect to be abstracted away by a unified GUI kit.

I absolutely would expect a unified GUI kit to be tremendously limited by selecting a common baseline of widgets that share functionality and forcing you to fit into a common paradigm that can be easily translated across platforms.

The problem is that in experience I see the exact opposite - I see "cross platform" kits that make me define my own right-click context entries when the conventions for those are heavily platform dependant. I need a right-click properies dialog... on Mac, I'd expect my toolkit to realize that this is called Get Info.

Again, that means creating more rigorous definitions. Where suddenly you just slapped on right-click menu items willy nilly, suddenly you actually have to consistently define "this is my properties menu-item" so that it appears correctly across multiple platforms. And that's a good thing - so many platform-specific GUI conventions are just that: conventions instead of being hard-coded.

How many times have people copied the Windows-standard menu items and re-coded "file->save, exit edit->copy, paste, select all help->about" and yadda yadda yadda.

I'd always expected to find GUI kits that properly codified these things, because they do exist on almost every program on platform they just have slightly different conventions that could easily be handled by the middleware.

But instead we just give the coder "here's a menu class" and they re-build teh Windows menu and nobody's surprised to find it's still the Windows menu on a Mac.

tl:dr;

The problem is that GUI kits encode just the implementation of the platform, when they also need to encode the conventions of a platform. I think we could see the "cross platform" kit have some measure of success if this were done.


> I keep hearing this kind of defeatism about cross-platform GUI items and it rubs me the wrong way.

To be fair, I do it anyway. My applications run on Windows, OS X, Linux and BSD. I even have a 'stub' GUI so that many can run on the command-line anywhere. I still believe that a Mac app that "sort of looks like a Windows app" is better than "no app at all." But I know that if I were selling a product, "good enough" wouldn't cut it.

It's a bit annoying though how Microsoft and Apple have extensive HIGs, and yet they constantly violate them and go in totally new directions anyway. At the least, it'd be nice if third-party vendors got the same apologist leeway to violate the HIGs, but I understand why first-party vendors get that and we don't, since it's their OS.

> I mean, a unified menubar vs the separate mene/titlebar of Windows/Gnome is exactly the kind of thing I'd expect to be abstracted away by a unified GUI kit.

It sounds like it, sure. Qt tries really hard to do a lot of this stuff. There are special flags you can set on menu items so your preferences and about items automagically move to the right spot. But it's deeply limited: sure it moves your about option, but it doesn't collapse the menu item separator above it, so your menu ends with a separator. Yes you can have a generic FileOpen dialog API, and there's a flag in Qt to make it use sheets too. But what if your app didn't expect another window to remain active during that modal event? This goes on and on and on and on and on.

"But you don't have to take my word for it," look at the reception of Qt apps among OS X users. The only time it's really accepted is when there's no Cocoa-native alternative.

And the more you abstract, the less control you have to really refine the end product. Probably the best and worst solution to cross-platform is going to be declarative user interfaces, something Qt has been dabbling in lately. I just really don't see that approach scaling to rich applications like graphics editors and music libraries.

> I absolutely would expect a unified GUI kit to be tremendously limited by selecting a common baseline of widgets that share functionality and forcing you to fit into a common paradigm that can be easily translated across platforms.

And end users won't like that. Windows users like that little spin box to select numeric values, and jump lists. OS X users like their badges on the dock icons. Gnome 3 users like their new fused title bar to system menu thing.

It's like 3D graphics and the uncanny valley. 90% isn't good enough. It's the little details that make someone say, "yeah, this is definitely a Mac OS X application."


> Sadly, the dream of write-once, run-anywhere and look nice is dead.

It's a shame no one invented the web browser yet :)


The web works for many classes of application, but it definitely does not work at all if you need raw CPU performance. And it never will with the likes of dynamic languages like Javascript. You're never going to see Dolphin, the Wii emulator, running decently inside of a web browser on top of JS, just because there's WebGL. It would also be idiotic as all hell for someone to run John the Ripper in Firefox.

The web is also the antithesis of platform consistency. Every last web page and web app is increasingly more and more about demonstrating artistic style.

Plus I really don't like being at the mercy of web apps. Google has shown me that they'll yank them away whenever they want, or just radically redesign it overnight and force me to use the new version, even if it loses functionality I needed.


I have a very good feeling telling that to byuu isn't going to end well...

That being said, byuu is absolutely correct. It's one thing to make a program look like all the other programs on the target platform, but it's something else entirely to make it feel like one as well. You'll need to compromise quite a bit, as even when you go into raw event-handling no two systems are alike. You can see olddocs/areaplan.md in my repo as an example of where this gets especially hair-pulling, or all the places in the documentation where I mark some subtlety as implementation-defined or system-defined.

Not even the big packages are immune. Look at Qt's QFormLayout type, which is a dedicated layout for aligning labels properly on each platform. (I'm going to have a similar thing eventually; that's why my docs presently have a TODO on vertical alignment with Label.)

And yes, human interface guidelines can differ in very subtle ways. As an example, take multiple-selection listboxes. There are two ways you can implement this: as a normal listbox that you can select multiple items of, or as a list of items with checkboxes that you check to mark as selected.

Microsoft's guidelines (http://msdn.microsoft.com/en-us/library/windows/desktop/dn74...) say (emphasis preserved) > Given this clear indication of multiple selection, you > might assume that check box lists are preferable to > standard multiple-selection lists. In practice, few tasks > require multiple selection or use it heavily; using a > check box list in such cases draws too much attention to > selection. Consequently, standard multiple-selection > lists are far more common.

GNOME's guidelines (https://developer.gnome.org/hig-book/stable/controls-lists.h...) say > Consider using a check box list for multiple-selection > lists, as these make it more obvious that multiple > selection is possible:

And Apple's guidelines (https://developer.apple.com/library/mac/documentation/UserEx...) don't say anything too clearly, but DO say that - scrolling lists are selected traditionally (not checkboxed) - but a menu-style list should use check marks instead

So there's that.


As someone who has worked extensively within Gnome's HIG, Apple's HIG, and with frameworks such as QT/GTK+/Cocoa, I fully agree with your and byuu's comments.

I was merely pointing out that the market seems to be pretty content with web apps as a solution to "write once, run anywhere, look nice" (even if here, the "look nice" doesn't include "look native" - but those are 2 different things)


Webapps hardly look more native than even unidiomatic cross-platform widget toolkits or whatever.


Webapps can "look nice" (the exact words of the parent comment) without being specifically "native", so I think the comment still stands.


In that case, I should have clarified "look nice, and native." I think most Qt applications do look nice on OS X. Nice alone just isn't good enough, though. They want consistency with their other applications.


It's not specific to OS X by the way.


There are a million different ways to look "platform-native". I'd like to know what exactly they got right and what they got wrong before simply jumping in.


For the record, and this applies to all comments above and below: by "platform-native" for this package, I do no custom drawing; everything is deferred out to the underlying system APIs. So this actually uses Cocoa on Mac OS X (you can see the .m files as well) and the Windows API on Windows (which is part of the reason I didn't go with just having Qt bindings).


wxWidgets and <del>Swing</del>SWT are also platform-native. Now find me a single wxWidgets and SWT app that doesn't look slightly off on Linux and OS X.

Looking and feeling native involves so much more than just using native controls.


Swing is NOT platform native, that's why SWT was developed in the first place. Swing can use native look-a-like theming but it's not the same thing as SWT's actual, truly native widgets (with native keyboard shortcuts, system services..).

wxWidgets and SWT are about as native at it can be in a cross platform GUI library. I don't see why you'd need a screenshot of the go library, it would look the same as a typical wxWidgets or SWT app, which is to say, it uses native controls, but might not be designed according to the "common" UI conventions of the platform.


Yes I meant SWT, but for some reason I wrote Swing.


Its native on OSX, is it not?


No, it only tries to look like OS X by drawing the controls like that. But there are still so many things off that I don't even know where to begin.


I love it when native-look-a-like apps give me blue buttons and traffic lights instead of the beautiful graphite I chose in my system preferences.


I use SWT quite a lot and while it's not perfect I find that it works brilliantly in most cases. I encourage the authors of this Go UI library to study SWT and crib heavily from the library internals. Otherwise they'll be sorting out bugs and corner cases that IBM has fixed in SWT long ago.


Seconded, I find SWT to be easy to program for too.


If you need to go native why not go with DWT?


I'll admit that it's the most exceptional trademark violation that I've seen today:

http://www.dsource.org/projects/dwt/wiki/Logo


No such thing in Linux.


Some screenshots would've been helpful even if it's platform-native, it's a good idea what the end result will look like.


Readme, check. Docs, check. Screenshots, nope. Why would you not include that for a gui library?


Stupid programmers with their writing code instead of making pictures.


Is it unreasonable to expect some kind of demonstration of what the code will accomplish before having to actually write a project which uses it?

If this code works and is tested on OS X, Windows, and Linux, then one would assume the author has at least one test implementation, so it wouldn't be too far of a stretch to screenshot it, especially given that cross-platform toolkits have never, in my experience, actually looked or felt native on OS X.


People on HN have a very bad habit of assuming that any time something appears on HN, it's because the authors wanted to put on a show for HN. No.


I can't speak for anyone else but I assumed they put it on github because they want other people to be able to use it.


It doesn't mean they're ready. Lots of stuff on GitHub is unfinished half-broke stuff. (And I don't fault anyone for that, because lots of my stuff on GitHub is like that.)


That's a bad assumption. You're saying I shouldn't commit code to GitHub until it's ready for release?


Oh please, what kind of excuse is that?

This library is clearly not written for the authors own personal benefit. Just look at the old readme; it's obviously written for other people to use and play with.

Examples and screenshots are good; there's no reason for anyone to be defensive about not having them; the author can just add them. It's no big deal; it's helpful feedback.


>> People on HN have a very bad habit of assuming that any time something appears on HN, it's because the authors wanted to put on a show for HN. No.

> Oh please, what kind of excuse is that?

Just demonstrated tptacek's point. The author could be at a point where he wants others to see, but isn't quite ready for places like HN yet. In that case, it's not an excuse. Attitudes like this encourage pathological perfectionism.


It is an excuse.

You don't need to polish something into a shiny gem of perfection before showing it to people; and you certainly don't need to get defensive about feedback (which in this case wasn't harsh at all); especially not for something out in the public that various people are already using.

Iterative feedback and improvement can only happen if you get feedback.

It's tempting to say that something isn't quite ready for others to see yet, it needs a bit more polish, and bit more internal beta testing, a bit more perfecting before you show it people.

...but I'd say that most cases, it's not the right attitude to encourage (although there are some very specific cases; like product launches where a botched launch has long term negative ramifications).

Have a think about what you wrote there.

You're endorsing self defensive attitude of perfectionism that you're criticizing.


You're endorsing self defensive attitude of perfectionism that you're criticizing.

No. I'm endorsing thinking a few steps ahead when criticizing. I think that should be the lower bar for feedback. Otherwise, it's too easy to engage in "feedback" as a means of self aggrandizement while humiliating others, which is as close as we can get to the Internet's official sport. (In particular, knee-jerk statements can be used to win over an uninformed crowd. They are the favorite ammunition of trolls.)


    Is it unreasonable to expect some kind of demonstration of what the code will 
    accomplish before having to actually write a project which uses it?
You think that perhaps danudey needed to stop for a moment and have a quiet think about that before posting it?

Perhaps word it in a more friendly way somehow?

Perhaps that it was a bit too harsh, and humiliated the original author?

I totally get the basic point you're making, but it's just completely ridiculous to be making it in this specific case.


You think that perhaps danudey needed to stop for a moment and have a quiet think about that before posting it?

Yes, and he should produce a tree of possibilities and if he doesn't have evidence precluding them all, he should briefly hypothesize about the most likely positive possibility while making his request for further information.

Another way to interpret this: He should think like a creator as opposed to a consumer. I think it's fair to ask this of visitors to GitHub, as it's fundamentally a site facilitating the process of creation.

We all need to do more reflection before writing, myself very much included. Unfortunately, the reward structure of the Internet combined with human nature seems to encourage the opposite.


Partially true; I was driven to write this because I wasn't particularly satisfied with what already existed for various differing reasons. The current feature set and my own short-term plans are based around the GUI projects that I intend to write first (specifically a music authoring program).

As for screenshots, I suppose I could upload a screenshot of the test program, but I'm not sure how much that would accomplish. I think a basic tutorial with screenshots at each step would probably be more useful, as it shows how the package works...


It would be quite helpful. I went to the README hoping to see how platform-native it is, even the test program would have been helpful.


It's amazing how many wheels need to be reinvented every time somebody introduces yet another language.


Do you mean the author is reinventing the wheel because this already exists in other programming languages, or because there are many existing GUI libraries like this in Go already? It's likely there are many people who are most comfortable writing Go recently so I don't understand how this is a problem.


Some folks at Microsoft were trying to circumvent this with Singularity OS being based on something like CLR. Then everything could dynamically interoperate with everything on a programming language level.

http://xkcd.com/927/


If I recall correctly, the point of Singularity wasn't to have a platform base where all programming languages shared the same infrastructure, but rather to have an operating system that ran (almost) entirely in "managed code" (the .net framework's safe-execution system).

.net itself is what you're thinking of.


ServerSwift! SwiftPOSIX! SwiftToJS! SwiftGTK! KSwift! WinSwift! SwiftCurse!


and the most important of all, 2048Swift, which of course happened already.

https://news.ycombinator.com/item?id=7845441


Could be a good Go-alternative of Xamarin in ~5 years or so.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: