Ask HN: What ideas in programming languages do you find difficult to code?
4 comments
I’ve implemented finite state machines multiple times (network protocols, format parsing, CNC controls, videogame AI, etc.) in different languages.
Found it surprisingly difficult to code well, regardless on the language, esp. when there're many states.
Found it surprisingly difficult to code well, regardless on the language, esp. when there're many states.
When some one complains about how async nodejs and callback are hells. I smile. FSM are notoriously hard to write, manage and debug. Because they are async by design.
In one of my prev workplaces we worked on state machines. Few good takeaways was to design state transition functions in a large array laid out with all possible hooks in order. And document the hell out ofit. Another approach was to generate boiler plate out of fsm given its grammar.
In one of my prev workplaces we worked on state machines. Few good takeaways was to design state transition functions in a large array laid out with all possible hooks in order. And document the hell out ofit. Another approach was to generate boiler plate out of fsm given its grammar.
For asynchronous IO, we now have async-await in many modern languages. The feature pretty much solves IO related callback hell; the compiler builds these state machines automatically, and keeps them abstracted behind a nice API making code easy to read, write and debug.
I wish someone would invent an approach suitable for generic FSMs, not just for async IO. External code generators work when you have grammar or protocol state UML, but aren’t without their problems.
I wish someone would invent an approach suitable for generic FSMs, not just for async IO. External code generators work when you have grammar or protocol state UML, but aren’t without their problems.
How about esterel? It seems to be a nice language based on FSM.
https://en.wikipedia.org/wiki/Esterel
Hey, I have really tried to give "state machine type tracking" a go in my current project [1] and try to expose JSON apis for them. Checkout the specific doc here:
http://docs.dapt.in/state_tracking/
Would love feedback.
[1] https://github.com/daptin/daptin
http://docs.dapt.in/state_tracking/
Would love feedback.
[1] https://github.com/daptin/daptin
I have coded a number of FSMs. I think the challenge is always in how much performance you want verse flexibility.
I think the challenge is quadratic growth of complexity with state size.
Here’s an example of FSM with relatively complex state, 1000-lines gc_execute_line function, it’s for CNC: https://github.com/grbl/grbl/blob/master/grbl/gcode.c
That’s not my code, but I’m not sure I would be able to do much better than that.
Here’s an example of FSM with relatively complex state, 1000-lines gc_execute_line function, it’s for CNC: https://github.com/grbl/grbl/blob/master/grbl/gcode.c
That’s not my code, but I’m not sure I would be able to do much better than that.
That code actually has me a bit confused. I don't understand how this part is working:
switch(letter) {
case 'G':
switch(int_value) {
case 4:
switch(int_value) { // int_value hasn't changed
case 10: ... // so how do we get to this case?
It’s not changing.
However, above that “case 4:” there’re another cases, “case 10: case 28: case 30: case 92: ” without break at the end of the code. Unlike some other languages, in C and C++ this means execution continues to the next case. The behavior is called "switch statement fallthrough".
That source code has the comment saying “No break. Continues to next line.”
However, above that “case 4:” there’re another cases, “case 10: case 28: case 30: case 92: ” without break at the end of the code. Unlike some other languages, in C and C++ this means execution continues to the next case. The behavior is called "switch statement fallthrough".
That source code has the comment saying “No break. Continues to next line.”
Ah, I missed that they didn't break above it. Thanks.
[deleted]
Strange as it sounds, a new language's syntax has become increasingly important and difficult to learn.
I learnt a bit of Go during weekends. I love the power and simplicity of concepts it brings in. But syntax is weird - func args and return is so weird. And variable declaration is verbose.
A language's syntax familarity with existing langauges like c, java, pythn, ruby etc.. Helps the speed at which experienced programmers process code. This is not just writing but also reading lot of open source code. If i dont feel upto speed with reading and writing - it kind of discourages.
I learnt a bit of Go during weekends. I love the power and simplicity of concepts it brings in. But syntax is weird - func args and return is so weird. And variable declaration is verbose.
A language's syntax familarity with existing langauges like c, java, pythn, ruby etc.. Helps the speed at which experienced programmers process code. This is not just writing but also reading lot of open source code. If i dont feel upto speed with reading and writing - it kind of discourages.
There's a common refrain you'll hear among Gophers. It goes something like: "I just wrote a 150+ line mind dump. And it successfully built on the first try. No errors. That's never happened before!" So stick with it. It's designed for that level of productivity ;)
I feel like I'm learning new concurrency patterns every week or so. Visualization tools like gotrace help, but it's still a mental twizzler. The first time you see chan type os.Signal, or func() or chan chan, you can't help think to yourself "why would anyone do this?" But as you begin to realize its not just about passing data but distributed control flow through your system, you gain more confidence in experimenting.
I feel like I'm learning new concurrency patterns every week or so. Visualization tools like gotrace help, but it's still a mental twizzler. The first time you see chan type os.Signal, or func() or chan chan, you can't help think to yourself "why would anyone do this?" But as you begin to realize its not just about passing data but distributed control flow through your system, you gain more confidence in experimenting.
I picked up "Concurrency in Go" (http://amzn.to/2xiGSmi) a few weeks ago. Total game changer on the concurrency part. It totally explains the whole model with a ton of examples and concurrency patterns. I'm still wrapping my head around a lot of it, but my day job code has improved significantly since even my first pass through the book. Highly recommend.
I'm still trying to wrap my head around garbage collection and other optimizations that we can make at a lower level. Go is so fun, though.
I'm still trying to wrap my head around garbage collection and other optimizations that we can make at a lower level. Go is so fun, though.
Erlang's syntax. Ouch.
Start with Prolog. Erlang's root is Prolog.
There's Elixir for that..
Unless you're working on a project already written in Erlang.
Also, my understanding (please correct me if I'm wrong) is that Elixir doesn't yet support all the language/runtime features that Erlang does. Has that changed in the past year or so?
Also, my understanding (please correct me if I'm wrong) is that Elixir doesn't yet support all the language/runtime features that Erlang does. Has that changed in the past year or so?
Maybe you struggle with object-oriented programming? Or maybe it's functional programming that's never clicked? Or maybe some other programming paradigm like stack-based programming (Forth) or goal-directed execution (Icon, Unicon).
Or is it a particular feature within a language (e.g Monads) that just doesn't make sense?
Do you avoid these ideas or features? Maybe you feel you have no need for them? Or do you still want to master or at least understand them better?
Or maybe you have the opposite problem: you know a pattern or feature so well that you reach for it every time regardless of whether it's suitable for the problem at hand? (Anyone brave enough to admit that :-)