3 ms·

[while checking Yegge's list the NBL should have:] >The final tally is 11 affirmative, 7 negative Yes, but among the negative are items with far most importan

by batista 14y ago

[while checking Yegge's list the NBL should have:] >The final tally is 11 affirmative, 7 negative Yes, but among the negative are items with far most importance than among the affirmative.

eckyptang 14y ago
I disagree. The negative items are things that people are used to but not necessarily the best solution to the problem: Perl regex: it covers most perl RE features that are important. The RE engine is the only real weak point I see in Go at the moment but that will change in time and it's "good enough" now. Strings and streams as collections: String is a collection of runes - you can get the rune at an index fine. The latter is just wrong - A stream is not byte addressable by nature. Iterators: for not good enough for you? You can build an iterator interface over any type if you desire that but it's really not needed. If it makes you comfortable... Generics: These are really not needed. This is a common misconception. I've come from a heavy OO C# background (DDD, 1000 class models etc) into Go and I've not missed them for a second. In fact I think I've probably been freed from a million bad design decisions and many refactor sessions. Standard OOP: I'm not even going down that route. The hacks you have to do to get proper composite models or some level of dynamicity using "standard OO" is horrible. I wish it would go away. CLOS is the nearest thing to something usable - not what C++, Java, C#, PHP force upon everyone. An there is a cross platform GUI for Go - it's called a web browser. The only nicety I'd like to see is dynamic loading as it'd allow composite, modular applications to be built without compilation but that has its own pitfalls.
- tsahyt 14y ago
  > An there is a cross platform GUI for Go - it's called a web browser. A web browser is NOT a replacement for a proper GUI library. Writing web GUIs is rather hard in comparison because that was not it's original intention. They're rather slow in comparison because they were not originally intended. The list goes on like this. Everything we did to HTML/CSS/JS in order to "support" those features better of the last decade were just workarounds and things to cover up the fact that we're still dealing with a Markup Language here which is supposed to add semantic meaning to a text or some other piece of information in order to display it. GUI libraries on the other hand were designed to do GUIs. They're designed not just to display information but to handle user input, handle widgets and components of user interfaces. Most importantly though they're designed to be consistent. Consistency is one of the most important aspects of user interface design and ultimately user experience. For example, look at Apple: The whole OSX experience and all the apps it comes with are consistent in look and feel. They've got the same polish on top and the same usability features that come with it. That is what takes most of the burden from users. You learn how to use it once and then you're able to apply that knowledge across many other applications. That is how things start to feel "intuitive". That is what all the UX designers are ultimately aiming for. HTML/CSS/JS enable us to build wildly different GUIs that do their job well but are not consistent for the most part of it. It has enabled designers to go on a rampage, each of them trying to improve on certain aspects. That's good, that's progress but it also comes at a great cost because things stop to feel intuitive and the paradigms of interaction you once learned are rendered invalid. Every site these days is trying to be different to stand out from the crowd and eventually it's all a bloody mess concerning overall UX. The only real use case for web GUIs are GUIs on the web, not native apps. Introducing the same mess we've got on the web nowadays to native desktop apps is not the right way to do it. A proper GUI library is the way to go both for the developer as well as for the user.
  - eckyptang 14y ago
    Perhaps I simplified a bit too much. I agree with you entirely. The browser provies an API and canvas on which you can build a user interface much as X provides it to Linux, GDI/WPF does for Windows and Quarts of OS-X. It's a medium, not the solution. I also agree about a lot of sites on the internet being a bloody UX mess.
  - nacker 14y ago
    Have you looked at http://pyjs.org http://pyjs.org ? I can't understand why it has got so little traction. Is GWT not considered a "proper" GUI library?
- batista 14y ago
  >I disagree. The negative items are things that people are used to but not necessarily the best solution to the problem That's what you say, and it might be true or not, but you don't get to use Yegge's list and count positives/negatives when you don't agree with Yegge's priorities.

by batista 14y ago

[while checking Yegge's list the NBL should have:] >The final tally is 11 affirmative, 7 negative Yes, but among the negative are items with far most importance than among the affirmative.

eckyptang 14y ago

I disagree. The negative items are things that people are used to but not necessarily the best solution to the problem: Perl regex: it covers most perl RE features that are important. The RE engine is the only real weak point I see in Go at the moment but that will change in time and it's "good enough" now. Strings and streams as collections: String is a collection of runes - you can get the rune at an index fine. The latter is just wrong - A stream is not byte addressable by nature. Iterators: for not good enough for you? You can build an iterator interface over any type if you desire that but it's really not needed. If it makes you comfortable... Generics: These are really not needed. This is a common misconception. I've come from a heavy OO C# background (DDD, 1000 class models etc) into Go and I've not missed them for a second. In fact I think I've probably been freed from a million bad design decisions and many refactor sessions. Standard OOP: I'm not even going down that route. The hacks you have to do to get proper composite models or some level of dynamicity using "standard OO" is horrible. I wish it would go away. CLOS is the nearest thing to something usable - not what C++, Java, C#, PHP force upon everyone. An there is a cross platform GUI for Go - it's called a web browser. The only nicety I'd like to see is dynamic loading as it'd allow composite, modular applications to be built without compilation but that has its own pitfalls.

tsahyt 14y ago
> An there is a cross platform GUI for Go - it's called a web browser. A web browser is NOT a replacement for a proper GUI library. Writing web GUIs is rather hard in comparison because that was not it's original intention. They're rather slow in comparison because they were not originally intended. The list goes on like this. Everything we did to HTML/CSS/JS in order to "support" those features better of the last decade were just workarounds and things to cover up the fact that we're still dealing with a Markup Language here which is supposed to add semantic meaning to a text or some other piece of information in order to display it. GUI libraries on the other hand were designed to do GUIs. They're designed not just to display information but to handle user input, handle widgets and components of user interfaces. Most importantly though they're designed to be consistent. Consistency is one of the most important aspects of user interface design and ultimately user experience. For example, look at Apple: The whole OSX experience and all the apps it comes with are consistent in look and feel. They've got the same polish on top and the same usability features that come with it. That is what takes most of the burden from users. You learn how to use it once and then you're able to apply that knowledge across many other applications. That is how things start to feel "intuitive". That is what all the UX designers are ultimately aiming for. HTML/CSS/JS enable us to build wildly different GUIs that do their job well but are not consistent for the most part of it. It has enabled designers to go on a rampage, each of them trying to improve on certain aspects. That's good, that's progress but it also comes at a great cost because things stop to feel intuitive and the paradigms of interaction you once learned are rendered invalid. Every site these days is trying to be different to stand out from the crowd and eventually it's all a bloody mess concerning overall UX. The only real use case for web GUIs are GUIs on the web, not native apps. Introducing the same mess we've got on the web nowadays to native desktop apps is not the right way to do it. A proper GUI library is the way to go both for the developer as well as for the user.
- eckyptang 14y ago
  Perhaps I simplified a bit too much. I agree with you entirely. The browser provies an API and canvas on which you can build a user interface much as X provides it to Linux, GDI/WPF does for Windows and Quarts of OS-X. It's a medium, not the solution. I also agree about a lot of sites on the internet being a bloody UX mess.
- nacker 14y ago
  Have you looked at http://pyjs.org http://pyjs.org ? I can't understand why it has got so little traction. Is GWT not considered a "proper" GUI library?
batista 14y ago
>I disagree. The negative items are things that people are used to but not necessarily the best solution to the problem That's what you say, and it might be true or not, but you don't get to use Yegge's list and count positives/negatives when you don't agree with Yegge's priorities.