Hacker News new | ask | show | jobs
by 3nt3 1370 days ago
I am currently being forced to use it for my compsci class and it really is horrible from a UI/UX standpoint (doesn't even have dark mode lol). It does not enforce any syntax style or proper formatting which makes beginners learn that "it doesn't matter" which is wrong imo and leads to horrible looking code.
3 comments

> It does not enforce any syntax style or proper formatting which makes beginners learn that "it doesn't matter" which is wrong imo and leads to horrible looking code.

This is a good point and IMO "format code on save" should be the default in most IDEs and editors - that way if you need a specific set of formatting rules you can configure them, but you won't end up with no formatting (or different people having different ways of writing code) by default.

I think that Go in Visual Studio Code did something like that by default, where you saved your changes and it also formatted everything. Annoying at first, but I came to appreciate the idea.

You can technically achieve the same with something like Git hooks but setting those up is error prone and can be annoying once people get too trigger happy (e.g. someone eventually putting running tests in Docker containers in there before you can commit your changes).

To me code formatting feels about the same as the tabs vs spaces "debate": if you're having it in the first place, you're possibly doing something wrong. Use tab key for indentation, have the IDE insert whatever is configured for the project/org, be it tabs or spaces (e.g. smart tabs), automate it away.

This is a tool for beginners. Formatting code on save might cause confusion. IMO professionally format on save sounds good if your expecting it. For a beginner they should learn the syntax and concepts. Formatting can be taught later.
I wish I could upvote this 100 times.

There is a world of difference between tools for learning how to code and tools for producing code.

Something students don't always realize is that their teacher doesn't need 30 copies of a program that prints "Hello, World". You are not "producing code", you are "demonstrating your understanding" of the content.

Autocomplete, autoformatting, auto-anything is harmful for the learning process. If the computer does it for you, then how do I know you know how to do it?

Once you can demonstrate that you know how to format your code properly, then those auto-tools can help you, rather than being a crutch.

Once you know "I can solve this problem by using a substring" you can use autocomplete to figure out the exact syntax for the substr() method. But if you're just looking through the auto-complete method list and clicking on things until one of them works... that's not "knowing how to program".

Go has a built-in tool for that (go fmt).

Coming back to BlueJ: I appreciate that beginners have to be taught to format their code properly sometime along the way, but not at the very beginning. If you have errors, warnings, linter hints, typos etc. all being highlighted, I imagine that must be confusing as hell for beginners. Better focus on fixing the syntax errors first (or learning how not to produce any in the first place). Also, over-eager linters such as ESLint can really suck all motivation out of you when writing code. As for automatic formatting, that's fine with languages where it's near-universal like Go, but for Java you should probably refrain from adding it to a tool such as BlueJ, otherwise you will get the opposite of what you wanted (people get used to the IDE doing it for them and then neglect proper formatting when the IDE doesn't).

See it through. I know sometimes at university it can feel like your having your wings clipped, or that your not getting the 'real' experience.

But it won't last forever, and what it does well - conveying often unintuitive OOP concepts - it does do well.

Your course conveners job its to teach the fundamentals, tooling is for you to shake out as you gain experience and scale up, and from their perspective - imagine trying to wrangle random IntelliJ/Eclipse issues with a cohort of 120+ students, for many whom this might be their first introduction to programming!

Scaling things back probably genuinely allows them to provide a better learning on ramp.

I'm still in high school so the scale of everything would probably not be an issue although I see your point of maintainability and showing the relations between classes graphically is probably also helpful when you're still wrapping your head around OOP concepts
Are you already familiar with better IDEs? Then of course using this is painful.

If you're learning to program for the first time, then i believe using a simpler tool is better, because there is less to learn all at once, and less that is hidden from you. I started programming in EditPad Lite, and that was absolutely what i needed until i started tackling larger projects, at which point it was worth spending the time to learn Eclipse.