Conception – An experimental modern IDE written in Go • Hacker News Board

Re: Conception – An experimental modern IDE written in Go

#51

Post by laumars » Sun, Jan 18, 2015, 5:16 PM UTC

zefei wrote: post #10

shurcooL wrote: post #5

Author here. I was just about to go sleep when I noticed a retweet and a lot of new stars on Conception; this explains it. The linked C++ project was the result of an initial year of working on it, which culminated in a winning entry to LIVE 2013 contest [1] and me switching to working on a version of it written completely in Go [2]. I no longer work actively on the C++ version, but I do on the Go one [3]. Primarily,…

Developers who re-invent/re-imagine some wheels usually realize at the end why the original wheels are designed like those. We, understandably, don't quite appreciate the work other people have done, where we consider their tradeoffs as mistakes. But when we do them ourselves, we eventually see the huge amount of conflicting goals, as tradeoff is the essence of engineering, or anything. However, almost all the good n…

> Developers who re-invent/re-imagine some wheels usually realize at the end why the original wheels are designed like those.

While that is true, I do also think it's healthy to have some scepticism about the design of projects because some are just poorly executed (either because it's based on an outdated model that everyone has stuck to because it's the standard way of doing things, or because of time constraints, or sometimes just because of a lack of love for the project).

Sometimes it's worth people re-inventing the while just to see for themselves as occasionally a new developer might just have a unique perspective that results in them solving a previously considered "unsolvable problem".

Obviously this philosophy isn't without it's drawbacks. But sometimes it's worth testing the old standards.

Re: Conception – An experimental modern IDE written in Go

#52

Post by vially » Sun, Jan 18, 2015, 5:22 PM UTC

mostafah wrote: post #6

Why should being written in a particular language matter? We see a lot of these “written in Go”s these days for a lot of new softwares. I’m a big user of Go myself. Love the language and use it for almost everything. But I just don’t get why an editor or IDE or static site generator or any other piece of software brag about using a particular language or library.

For me the fact that Go programs don't have a runtime dependency like python or ruby makes a big difference. There are a lot of cool projects written in python or ruby which I would love to try but knowing that I have to setup rbenv/rvm/virtualenv/etc just to try it is a big inconvenience for me (or you could just install it globally for the system/user but I generally avoid that).

Re: Conception – An experimental modern IDE written in Go

#53

Post by tree_of_item » Sun, Jan 18, 2015, 5:42 PM UTC

V-2 wrote: post #49

tree_of_item wrote: post #46

Earlier quoted context omitted.

Who cares how long the file is? That's not what "spaghetti" means, what matters is the formal structure of the code.

> Who cares how long the file is? Every software developer worth his (or her) salt. > what matters is the formal structure of the code Yes, and splitting code into well named files is a starting point for giving it proper structure. The same goes for the size of your functions. Here some (like "ProcessEvent") consist of nearly 500 lines... that's roughly 10 screens. Textbook spaghetti code. Overly long code files are…

This is one of those "software engineering best practices" that sounds nice but has no basis in reality. What matters is the formal structure of your program: types, composition, state, capabilities. Where your code is located on the filesystem is incidental complexity.

My thinking is more along the lines of http://erlang.org/pipermail/erlang-questions/2011-May/058768... and http://tonymorris.github.io/blog/posts/identifier-names/, but I bet your professional literature would be apopleptic at suggestions like these :]

Re: Conception – An experimental modern IDE written in Go

#54

Post by V-2 » Sun, Jan 18, 2015, 6:18 PM UTC

tree_of_item wrote: post #53

V-2 wrote: post #49

Earlier quoted context omitted.

> Who cares how long the file is? Every software developer worth his (or her) salt. > what matters is the formal structure of the code Yes, and splitting code into well named files is a starting point for giving it proper structure. The same goes for the size of your functions. Here some (like "ProcessEvent") consist of nearly 500 lines... that's roughly 10 screens. Textbook spaghetti code. Overly long code files are…

This is one of those "software engineering best practices" that sounds nice but has no basis in reality. What matters is the formal structure of your program: types, composition, state, capabilities. Where your code is located on the filesystem is incidental complexity. My thinking is more along the lines of http://erlang.org/pipermail/erlang-questions/2011-May/058768... and http://tonymorris.github.io/blog/posts/ide…

> This is one of those "software engineering best practices" that sounds nice but has no basis in reality

Are you a programmer? What languages?

> Where your code is located on the filesystem is incidental complexity.

Incidental complexity is still complexity to deal with.

It isn't easy for me as a developer to find such and such routine if you've thrown everything into a big bucket named "main".

You also omitted the fact that I didn't only refer to files. I mentioned the size of functions, too. Now functions ARE logical units of code, and if you need to scroll ten screens and names are as vague as "ProcessEvent" (which is not broken down into subroutines), this doesn't speak very well about the overall design.

Thanks for the links - but it's hard not to notice that they both refer to FP languages, however (Erlang and Scala).

I wouldn't step out to judge the quality of an Erlang codebase, because that's not a paradigm I'm well familiar with.

Go, however, doesn't belong to that family. I see no reason why SRP and other oldschool principles wouldn't apply here. I'd be happy if someone told me (that's why I asked at the beginning - "or is that the language"?).

The other commenter (@mod) implied that since the project is experimental, it's done quick and dirty but that's because it's prototyping.

Note that I've never said the author of the project is a sloppy programmer, I only wondered at the code being so messy.

Re: Conception – An experimental modern IDE written in Go

#55

Post by shurcooL » Sun, Jan 18, 2015, 6:31 PM UTC

keyle wrote: post #26

Lovely. Here is some cheap feedback from a UX perspective. Give a bit of padding to your text blocks Identify clearly the input from output And adding syntax colouring will give it 300% sweetness.

The Go version has had syntax highlighting for a while now. :)

Re: Conception – An experimental modern IDE written in Go

#56

Post by shurcooL » Sun, Jan 18, 2015, 6:36 PM UTC

V-2 wrote: post #44

Sweet lord, https://github.com/shurcooL/Conception-go/blob/master/main.g... is nearly 9k lines long! What a spaghetti. Is that the author or the language?

It's an open issue, please see https://github.com/shurcooL/Conception-go/issues/3 for more context.

It was helpful to me to keep everything in a huge file during initial development for a few reasons:

- I wanted to learn what happens when you break the convention that a project should be split into many files.

- I wanted to test the limits of various tools I am using and building. The main.go kinda works as a worst case scenario so I can look at performance of my code and existing tools like sublime text, goimports, gocode, etc.

- It allowed me to make faster progress implementing tasks in my limited free time, and I plan to delete/refactor the code to be nicer and more readable over time.

It's effectively a compromise/trade off, I did not optimize for having the cleanest code as my top priority.

Re: Conception – An experimental modern IDE written in Go

#57

Post by dragonwriter » Sun, Jan 18, 2015, 6:36 PM UTC

V-2 wrote: post #44

Sweet lord, https://github.com/shurcooL/Conception-go/blob/master/main.g... is nearly 9k lines long! What a spaghetti. Is that the author or the language?

How long files, functions, or other miles is a legitimate concern, but its a different design issue than "spaghetti code".

Re: Conception – An experimental modern IDE written in Go

#58

Post by fishnchips » Sun, Jan 18, 2015, 7:24 PM UTC

exit wrote: post #40

fishnchips wrote: post #28

This looks insanely cool (congrats!) but from a purely practical perspective I'm not sure if I'd want to use it even if it was a perfect, finished product. After all, I'd have to forget everything I ever learned about text editors and IDEs.

"If a man cannot forget, he will never amount to much." - Kierkegaard

"Good enough is the enemy of the great" - Grumpy Cat (attributed)

Re: Conception – An experimental modern IDE written in Go

#59

Post by GFK_of_xmaspast » Sun, Jan 18, 2015, 7:25 PM UTC

V-2 wrote: post #49

tree_of_item wrote: post #46

Earlier quoted context omitted.

Who cares how long the file is? That's not what "spaghetti" means, what matters is the formal structure of the code.

> Who cares how long the file is? Every software developer worth his (or her) salt. > what matters is the formal structure of the code Yes, and splitting code into well named files is a starting point for giving it proper structure. The same goes for the size of your functions. Here some (like "ProcessEvent") consist of nearly 500 lines... that's roughly 10 screens. Textbook spaghetti code. Overly long code files are…

That's not what 'spaghetti code' means.

Re: Conception – An experimental modern IDE written in Go

#60

Post by loevborg » Sun, Jan 18, 2015, 7:32 PM UTC

mod wrote: post #47

mostafah wrote: post #20

Earlier quoted context omitted.

You’re right. What makes this project interesting is the idea and the design, not Go, yet it would be much harder to get this publicity through that. And that’s exactly what I’m saying: why should people upvote just because of the language?

People can be interested in the link for two different reasons, now. Some people want to see a new editor; some people want to see the source code. I have a search set up that emails me daily about Clojure topics on HN. I'd be very interested to see new editors written in Clojure, and not very interested in using the editors themselves.

Setting up email alerts for Clojure stories sounds useful. Can you describe how you do that? I couldn't find a way to set up alerts, either using hn.algolia.com or using Google Alerts.