Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix as IDE

sanctum.geek.nz

Post reply on HN
Print view View original

71–80 of 214 posts

Re: Unix as IDE

#71

Post by toomanybeersies »

AceJohnny2 wrote: post #35
amelius wrote: post #34

Earlier quoted context omitted.

If you can't debug with just print statements, you're doing it wrong :)

It's funny but, in the embedded world, it's scary how archaic things are. For example, just a few hours ago I convinced a colleague to try using the debugger. Our hardware has had a functional JTAG-based debugging toolchain for years, but people still haven't picked up on it. I'm the new guy who spearheaded it in the team -_-

For my 200 and 300 level embedded software papers, I was essentially stuck with using flashing leds and printf to debug code.

For my 400 level embedded systems design paper (which was actually a hardware design paper, we weren't graded on the code), we built boards that we could program and debug with JTAG.

I was stuck on a pain point for hours until one of the tutors showed me how to use GDB with the boards via JTAG. It took me literally 5 minutes to fix the problem. Being able to step through the code line by line allowed me to see exactly where it was breaking, and why it was breaking.

If I'm ever doing embedded development again (unlikely as I'm now employed as a web developer), I don't think I'll be able to function at all without a proper debugging environment.

Re: Unix as IDE

#72

Post by catnaroek »

qwertyuiop924 wrote: post #24
catnaroek wrote: post #21

Earlier quoted context omitted.

Lisp's syntax is okay, but its semantics is absolutely horrendous. Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages), Lisp is an even worse low-level systems language. In the 80's, the only way one could reasonably hope to use Lisp as a systems l…

Well, some of us like Dynamic Typing. Just because you don't doesn't make it horrendous. Given, it can be unpleaseant in certain contexts, but Lisp has really good metaprogramming support, so you can add syntax for a runtime type system relatively simply. It's not optimal, and it certaibly isn't the fastest thing, but it works if you want it. And nowadays, CL (and several of the Schemes) provide more powerful type sy…

I don't have anything against the presence of dynamic typing - it's in fact very useful. What's annoying is the absence of meaningful static typing: parametric polymorphism and exhaustive pattern matching help me prove things about what my code does and how it can be used by others, but their usefulness is reduced to zero when dynamically typed code is allowed to break the proofs' assumptions. To be perfectly clear: it doesn't bother me in the slightest that a dynamically typed module can break the internal state of another dynamically typed module, since in most likelihood I'm the author of neither, and I respect other people's right to write their code however they wish. So I'd be fine with a Racket-like contract system, where well-typed modules can't be blamed. But, if I understand correctly, what Common Lisp has is nothing like this.

Re: Unix as IDE

#73

Post by reddit_clone »

RX14 wrote: post #64
ktRolster wrote: post #47

Earlier quoted context omitted.

"My primary debugging tool is Console.Writeline(). To be honest, I think that's true of a lot of programmers." --Anders Hejlsberg If Anders Hejlsberg does it, there's no shame in it.

There's no shame in it but that doesn't mean that it's the best or most efficient way of doing things. I've found that stepping through code in a debugger at a human pace, and getting to really understand what's happening when a bug occurs is invaluable.

I don't trust debuggers with multi-threaded programs.

Organized (multi verbose level) tracing built right into the application can go a long way before you actually need a debugger.

Re: Unix as IDE

#74

Post by AceJohnny2 »

swah wrote: post #59
AceJohnny2 wrote: post #35

Earlier quoted context omitted.

It's funny but, in the embedded world, it's scary how archaic things are. For example, just a few hours ago I convinced a colleague to try using the debugger. Our hardware has had a functional JTAG-based debugging toolchain for years, but people still haven't picked up on it. I'm the new guy who spearheaded it in the team -_-

In the embedded world the quote from Mickens "I HAVE NO TOOLS BECAUSE I'VE DESTROYED MY TOOLS WITH MY TOOLS" happens much more frequently :)

I used that quote just yesterday >_>

Re: Unix as IDE

#75

Post by AceJohnny2 »

toomanybeersies wrote: post #71
AceJohnny2 wrote: post #35

Earlier quoted context omitted.

It's funny but, in the embedded world, it's scary how archaic things are. For example, just a few hours ago I convinced a colleague to try using the debugger. Our hardware has had a functional JTAG-based debugging toolchain for years, but people still haven't picked up on it. I'm the new guy who spearheaded it in the team -_-

For my 200 and 300 level embedded software papers, I was essentially stuck with using flashing leds and printf to debug code. For my 400 level embedded systems design paper (which was actually a hardware design paper, we weren't graded on the code), we built boards that we could program and debug with JTAG. I was stuck on a pain point for hours until one of the tutors showed me how to use GDB with the boards via JTAG…

> I was essentially stuck with using flashing leds and printf to debug code.

Should be enough for anyone. Some people used flashing LEDs to dump an entire firmware! ;)

http://hackaday.com/2008/05/27/porting-chdk-to-new-cameras/

Re: Unix as IDE

#77

Post by dasil003 »

coldtea wrote: post #38
__jal wrote: post #32

This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. When IDEs (the kind that comes as a GUI'ed bundle of things thought to be the most appropriate for the purpose by committee of someones, somewhere) started becoming popu…

> This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness…

Another problem is the scope of the stack and problem space to be addressed. Someone can easily come up with a better solution to some subset of the problem, but it won't be interoperable and have the features necessary to solve the problem that all the people using the original solution expect. If you have a big enough fundamental improvement you can motivate the change to happen over time, but by the time that transition is done you've accumulated a whole different set of crufty legacy.

Re: Unix as IDE

#78

Post by sedachv »

jcoffland wrote: post #19
_vya7 wrote: post #4

At some point I realized Unix is basically a long-running IDE + REPL, and thought that was just so cool . And then I realized how horribly inefficient it is at being that. So I started longing for the days when we had some kind of OS where it actually is a IDE + REPL, like an OS based on Lisp. And then I learned that that already was done and didn't turn out as cool as people had hoped. Oh well.

> And then I realized how horribly inefficient it is at being that. This depends a lot on the user. In the right hands it's extremely efficient.

> This depends a lot on the user. In the right hands it's extremely efficient.

IMO the inefficiency is more due to the fundamental brokenness of the Unix process model. A Unix process is sort of like a VM with none of the security, and all of the stuff that has been added to it over the years (signals, IPC, dynamic linking) just makes it worse and worse. Things like full machine virtualization and now over the past 15 years namespaces/cgroups/containers are very complicated, brittle ways of trying to work around the shortcomings of Unix processes. This IMO is the biggest advance plan9 made over Unix.

Re: Unix as IDE

#79

Post by qwertyuiop924 »

catnaroek wrote: post #72
qwertyuiop924 wrote: post #24

Earlier quoted context omitted.

Well, some of us like Dynamic Typing. Just because you don't doesn't make it horrendous. Given, it can be unpleaseant in certain contexts, but Lisp has really good metaprogramming support, so you can add syntax for a runtime type system relatively simply. It's not optimal, and it certaibly isn't the fastest thing, but it works if you want it. And nowadays, CL (and several of the Schemes) provide more powerful type sy…

I don't have anything against the presence of dynamic typing - it's in fact very useful. What's annoying is the absence of meaningful static typing: parametric polymorphism and exhaustive pattern matching help me prove things about what my code does and how it can be used by others, but their usefulness is reduced to zero when dynamically typed code is allowed to break the proofs' assumptions. To be perfectly clear:…

I don't know. I'm not a CL user. I understand that they actually do have a type system, which can be used to verify that your inputs are of the correct type and match your assumptions. As for contracts, I wouldn't be surprised if someone wrote a macro for it: they're not exactly rocket science, at their simplest.

Don't ask me: I'm using Chicken Scheme, which provides both (to an extent: The documentation is worryingly vague about how the type system handles failure).

Re: Unix as IDE

#80

Post by catnaroek »

lispm wrote: post #29
catnaroek wrote: post #21

Earlier quoted context omitted.

Lisp's syntax is okay, but its semantics is absolutely horrendous. Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages), Lisp is an even worse low-level systems language. In the 80's, the only way one could reasonably hope to use Lisp as a systems l…

Nice rant, but mostly wrong. > Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages) There are many more high-level features, than static semantics. Lisp is designed for runtime flexibility, not static semantics. Runtime flexibility allows lots of in…

> 10 Mbyte. Today Lisp runs fine on an modern processor and some people tinker with Lisp-based operating systems, again.

My main desktop machine has 16 GB RAM, and its processor cycle speed is probably also 1600 times as much as that of a machine from back then. Why can't I get my computer to perform 1600 times as much concurrent work as back then?

> Every iPhone does that now, since Apple's Objective-C and the iOS frameworks are actually that: efficient dynamic allocation, of runtime-typed small and large objects.

That's a luxury that we can nowadays afford. Even the cheapest entry-level smartphone is ridiculously more powerful than an 80's era workstation. But the amount of work computers do for us hasn't grown proportionally to the amount of computing power.

Post reply on HN