5 ms·

I would be extremely surprised to see a language having no class, no inheritance and no good IDE become successfull in modern app development. Android devs are

by bsaul 12y ago

I would be extremely surprised to see a language having no class, no inheritance and no good IDE become successfull in modern app development. Android devs are used to such a different type of programming, i don't expect them to accept banging their heads on so many walls for such little gains. Ps : my stand is the opposite for server side dev.

Morgawr 12y ago
Maybe this will help people (like me, for instance) who are disgusted by the overengineered OOP-heavy approach of most Java frameworks but enjoy the concise and elegant simplicity of languages like Go to finally move over and try out Android development.
- bsaul 12y ago
  Sure, the java bloated ecoystem is a real issue. Yet, imagine yourself building UI component without classes or inheritance ? Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". GUI is to me the field where inheritance actually makes a lot of things easier and natural. Now you may end up with something similar using struct inheritance and manually overriding function for the given type, but i doubt most devs will go past the first unsuccesfull attempts.
  - burntsushi 12y ago
    > Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". Of course you can do that in Golang. You don't need inheritance. It has composition with type embedding. You can even "override" methods. http://play.golang.org/p/UV55gQj7t0 http://play.golang.org/p/UV55gQj7t0
    - bsaul 12y ago
      I know you can, i've explicitly talked about struct inheritance in my comment, as well as manually defining functions for the new type. Yet, this is a weird construct if all you want to do is class inheritance. You have to deal with questions like "do i want to define the func on my type, or on a pointer to that type", or "how do i call "super"", how do i extend the constructor for that new type, etc.. All those questions do have answers in golang. But you have to learn new patterns in order to do an extremely basic and common thing in OOP, once again, without much immediate apparent benefit.
      - burntsushi 12y ago
        > i've explicitly talked about struct inheritance in my comment It's not struct inheritance[1], so I wasn't sure what you were talking about. [1] - http://golang.org/ref/spec#Struct_types http://golang.org/ref/spec#Struct_types
    - scottlamb 12y ago
      > You can even "override" methods. That's not the same thing as overriding a virtual method in an OO language. If B() calls A(), it gets the general A: http://play.golang.org/p/nu7kY168E9 http://play.golang.org/p/nu7kY168E9
      - burntsushi 12y ago
        ... hence the scare quotes ...
  - Morgawr 12y ago
    >imagine yourself building UI component without classes or inheritance I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and elegant. I honestly see no problem whatsoever.
    - tormeh 12y ago
      Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.
      - NateDad 12y ago
        There is almost never code that requires inheritance.
        jrockway 12y ago
        Inheritance, in practice, is cut-n-paste for people that think they're too smart for cut-n-paste. "Give me an object like Foo, but with this one little thing changed."
        xienze 12y ago
        Sure, you can clone Foo into Bar and change one thing in Bar. But what happens when you need to change functionality common between Foo and Bar? Oh right, you have to change the same thing in two places now. Doesn't seem so smart anymore...
        NateDad 12y ago
        This is why Go has standalone functions and interfaces. You can easily share logic between types without having the types be the same thing. The biggest problem with inheritance is that it's a lot like monkey patching (except in production)... the rest of the base class's code expects method X to do ABC, and you've just swapped out the implementation to do LMNO ... and if that never bites you in the ass, you're luckier than most OO programmers I know.
  - 4ydx 12y ago
    Embedded types are king.
  - spopejoy 12y ago
    GUI is to me the field where inheritance actually makes a lot of things easier and natural. I would invert that and say GUI frameworks are why bad OO/excessive inheritance is so ubiquitous. I have no idea why all the major frameworks have these horrible inheritance hierarchies, there's really no excuse for it. In my UI days, I would avoid this by having a Window or Component class extend nothing, housing the necessary component as a field. I'd extend it only if I had to (rarely, and even then usually just one or two methods), and expose it with a getter. Cleaned things up a LOT.
dragonwriter 12y ago
It nay not become popular among existing, heavily invested mobile devs, but they aren't the only devs who might target mobile. And the fashion of class-based OO and languages that require heavy IDEs seems to be increasingly less accepted as the one true way.
- bsaul 12y ago
  Not sure where you got that feeling : Android studio was just released a few weeks ago and became the official IDE for android. Xcode advocates building GUI using Wysiwyg tool. Swift has all the OOP features, and it also has an embedded "playground" mode, inside the IDE itself. I don't think the trend is toward slim environments. There will always be people to say that doing things manually is better than having the computer do it, but it always surprises me when this thought comes from programmers themselves. Note : i would actually love to have a great IDE for golang, with all kinds of refactoring, code analysis and autocompletion features ( lightIDE isn't one of them yet). I dont't think big IDEs are incompatible with elegant language, as swift+xcode or visual studio+C# show. To me the problem with Java is that there isn't a single framework that you could actually use if your only editor is emacs.
  - dragonwriter 12y ago
    > There will always be people to say that doing things manually is better than having the computer do it Languages that don't require a heavy IDE (particularly one including lots of tools for writing and rewriting code -- static analysis tools are a different issue) aren't "doing things manually instead of having the computer do it" -- interacting with the language itself is no more "manual" than interacting directly with the IDE. Its just aligning the write-language with the read-language. If I need a separate visual language to use to write code from the language I'm nominally working in, that both increases the overall mental complexity and indicates that there are weaknesses in the abstractions available in the nominal working language.
    - bsaul 12y ago
      I understand your point, although i don't think OOP has anything to do with ( as C# and swift demonstrate). I disagree on your "read language" vs "write language" analogy. Take for example SQL and Database model designer. Both are useful, and the fact that the second makes things easier doesn't diminish the merits of the first.
SixSigma 12y ago
> Android devs there are plenty of non-Android devs, like me, that just don't want to go with Java and are not fussed about IDEs. I know full well there are plenty like me in the Go community.
jud_white 12y ago
> no good IDE LiteIDE is open source, cross-platform and pretty enjoyable. https://code.google.com/p/liteide/ https://code.google.com/p/liteide/
- jksmith 12y ago
  +1
- bsaul 12y ago
  It's the one i'm currently using, but calling it enjoyable is really excessiv. You can't compile or get any kind of completion while running your program, you can't define a script to be called when hitting "run" ( it always tries to launch your current file). It doesn't have any kind of macro or refactoring features, etc.. Coming from xcode and pycharm, it still feels a decade younger.
TeeWEE 12y ago
The main use of go for android, is to write native apps (games) in go, using a simple draw loop, that calls into OpenGL. In this way you can have one codebase for your game on android and ios (go will support ios too in the future). I think it was never meant todo UI android development, because that requires calling into java a lot. Since most of android IS java.
SEJeff 12y ago
Got has inheritance, or at least the same idea, just done a bit differently: http://golangtutorials.blogspot.com/2011/06/inheritance-and-subclassing-in-go-or.html http://golangtutorials.blogspot.com/2011/06/inheritance-and-... I'd also argue that by being designed to be machine refactored and parsed (unlike some dynamically typed languages), go is easier to wrap with an IDE for refactoring stuff.
vegedor 12y ago
I think success is relative to the goals of the language. As a system language that place is in areas where performance matters. Performance might be an issue on mobile in general, with regards to battery life, but in business terms optimizations costs money and people like to carry datacenters in their pockets anyway, so the benefit of a slightly more efficient language is a moot point. With low expectations in mind it might be a minor success for anyone who likes to use it for the languages sake. I wouldn't know about that, because I don't use go and should therefore not really comment in a go thread but here we go, I wrote it already. (pun not intended)

by bsaul 12y ago

Morgawr 12y ago

Maybe this will help people (like me, for instance) who are disgusted by the overengineered OOP-heavy approach of most Java frameworks but enjoy the concise and elegant simplicity of languages like Go to finally move over and try out Android development.

bsaul 12y ago
Sure, the java bloated ecoystem is a real issue. Yet, imagine yourself building UI component without classes or inheritance ? Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". GUI is to me the field where inheritance actually makes a lot of things easier and natural. Now you may end up with something similar using struct inheritance and manually overriding function for the given type, but i doubt most devs will go past the first unsuccesfull attempts.
- burntsushi 12y ago
  > Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". Of course you can do that in Golang. You don't need inheritance. It has composition with type embedding. You can even "override" methods. http://play.golang.org/p/UV55gQj7t0 http://play.golang.org/p/UV55gQj7t0
  - bsaul 12y ago
    I know you can, i've explicitly talked about struct inheritance in my comment, as well as manually defining functions for the new type. Yet, this is a weird construct if all you want to do is class inheritance. You have to deal with questions like "do i want to define the func on my type, or on a pointer to that type", or "how do i call "super"", how do i extend the constructor for that new type, etc.. All those questions do have answers in golang. But you have to learn new patterns in order to do an extremely basic and common thing in OOP, once again, without much immediate apparent benefit.
    - burntsushi 12y ago
      > i've explicitly talked about struct inheritance in my comment It's not struct inheritance[1], so I wasn't sure what you were talking about. [1] - http://golang.org/ref/spec#Struct_types http://golang.org/ref/spec#Struct_types
  - scottlamb 12y ago
    > You can even "override" methods. That's not the same thing as overriding a virtual method in an OO language. If B() calls A(), it gets the general A: http://play.golang.org/p/nu7kY168E9 http://play.golang.org/p/nu7kY168E9
    - burntsushi 12y ago
      ... hence the scare quotes ...
- Morgawr 12y ago
  >imagine yourself building UI component without classes or inheritance I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and elegant. I honestly see no problem whatsoever.
  - tormeh 12y ago
    Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.
    - NateDad 12y ago
      There is almost never code that requires inheritance.
      - jrockway 12y ago
        Inheritance, in practice, is cut-n-paste for people that think they're too smart for cut-n-paste. "Give me an object like Foo, but with this one little thing changed."
        xienze 12y ago
        Sure, you can clone Foo into Bar and change one thing in Bar. But what happens when you need to change functionality common between Foo and Bar? Oh right, you have to change the same thing in two places now. Doesn't seem so smart anymore...
        NateDad 12y ago
        This is why Go has standalone functions and interfaces. You can easily share logic between types without having the types be the same thing. The biggest problem with inheritance is that it's a lot like monkey patching (except in production)... the rest of the base class's code expects method X to do ABC, and you've just swapped out the implementation to do LMNO ... and if that never bites you in the ass, you're luckier than most OO programmers I know.
- 4ydx 12y ago
  Embedded types are king.
- spopejoy 12y ago
  GUI is to me the field where inheritance actually makes a lot of things easier and natural. I would invert that and say GUI frameworks are why bad OO/excessive inheritance is so ubiquitous. I have no idea why all the major frameworks have these horrible inheritance hierarchies, there's really no excuse for it. In my UI days, I would avoid this by having a Window or Component class extend nothing, housing the necessary component as a field. I'd extend it only if I had to (rarely, and even then usually just one or two methods), and expose it with a getter. Cleaned things up a LOT.

dragonwriter 12y ago

It nay not become popular among existing, heavily invested mobile devs, but they aren't the only devs who might target mobile. And the fashion of class-based OO and languages that require heavy IDEs seems to be increasingly less accepted as the one true way.

bsaul 12y ago
Not sure where you got that feeling : Android studio was just released a few weeks ago and became the official IDE for android. Xcode advocates building GUI using Wysiwyg tool. Swift has all the OOP features, and it also has an embedded "playground" mode, inside the IDE itself. I don't think the trend is toward slim environments. There will always be people to say that doing things manually is better than having the computer do it, but it always surprises me when this thought comes from programmers themselves. Note : i would actually love to have a great IDE for golang, with all kinds of refactoring, code analysis and autocompletion features ( lightIDE isn't one of them yet). I dont't think big IDEs are incompatible with elegant language, as swift+xcode or visual studio+C# show. To me the problem with Java is that there isn't a single framework that you could actually use if your only editor is emacs.
- dragonwriter 12y ago
  > There will always be people to say that doing things manually is better than having the computer do it Languages that don't require a heavy IDE (particularly one including lots of tools for writing and rewriting code -- static analysis tools are a different issue) aren't "doing things manually instead of having the computer do it" -- interacting with the language itself is no more "manual" than interacting directly with the IDE. Its just aligning the write-language with the read-language. If I need a separate visual language to use to write code from the language I'm nominally working in, that both increases the overall mental complexity and indicates that there are weaknesses in the abstractions available in the nominal working language.
  - bsaul 12y ago
    I understand your point, although i don't think OOP has anything to do with ( as C# and swift demonstrate). I disagree on your "read language" vs "write language" analogy. Take for example SQL and Database model designer. Both are useful, and the fact that the second makes things easier doesn't diminish the merits of the first.

SixSigma 12y ago

> Android devs there are plenty of non-Android devs, like me, that just don't want to go with Java and are not fussed about IDEs. I know full well there are plenty like me in the Go community.

jud_white 12y ago

> no good IDE LiteIDE is open source, cross-platform and pretty enjoyable. https://code.google.com/p/liteide/ https://code.google.com/p/liteide/

jksmith 12y ago
+1
bsaul 12y ago
It's the one i'm currently using, but calling it enjoyable is really excessiv. You can't compile or get any kind of completion while running your program, you can't define a script to be called when hitting "run" ( it always tries to launch your current file). It doesn't have any kind of macro or refactoring features, etc.. Coming from xcode and pycharm, it still feels a decade younger.

TeeWEE 12y ago

The main use of go for android, is to write native apps (games) in go, using a simple draw loop, that calls into OpenGL. In this way you can have one codebase for your game on android and ios (go will support ios too in the future). I think it was never meant todo UI android development, because that requires calling into java a lot. Since most of android IS java.

SEJeff 12y ago

Got has inheritance, or at least the same idea, just done a bit differently: http://golangtutorials.blogspot.com/2011/06/inheritance-and-subclassing-in-go-or.html http://golangtutorials.blogspot.com/2011/06/inheritance-and-... I'd also argue that by being designed to be machine refactored and parsed (unlike some dynamically typed languages), go is easier to wrap with an IDE for refactoring stuff.

vegedor 12y ago

I think success is relative to the goals of the language. As a system language that place is in areas where performance matters. Performance might be an issue on mobile in general, with regards to battery life, but in business terms optimizations costs money and people like to carry datacenters in their pockets anyway, so the benefit of a slightly more efficient language is a moot point. With low expectations in mind it might be a minor success for anyone who likes to use it for the languages sake. I wouldn't know about that, because I don't use go and should therefore not really comment in a go thread but here we go, I wrote it already. (pun not intended)